The Security Leader’s Next Moves

If a system can fail, the question is not whether to invent a new security discipline for it. The question is whether the architecture still limits what failure can reach. Most of the answer lies in familiar controls: identity, least privilege, data classification, network and application boundaries, monitoring, and recovery. AI does not make these obsolete. It makes their placement and enforcement more consequential.

Consider a company’s internal assistant. It can search policy documents, summarize support tickets, and open requests in a service-management system. The model may be new; the security questions are not. Which identity is making each request? What records can that identity read? Can it change anything, or only propose a change? Are its actions logged in a way investigators can attribute to a person, an agent, and the tool involved?

The architectural wrinkle is that an AI workflow may carry a user’s authority into places the user would not navigate directly. A person can ask a question in ordinary language; the system may then retrieve files, call APIs, or pass information to another service. A familiar login screen, therefore, tells you little about the full path of authority and data. Map the workflow, not just the model.

Keep the controls; redraw the boundaries

Identity remains the first control plane. Use attributable workload identities or scoped delegation on behalf of a user, as the task requires. Avoid shared administrator credentials and unrestricted reuse of a human session. Preserve the user’s access limits in user-directed workflows, tie access to a defined task, and make revocation practical. Where a human must approve a consequential step, ensure the person can see what will happen, with which data, and under whose authority—not merely click “Approve” on an opaque action.

Data access needs the same discipline. Retrieval systems and connectors can expose information without an agent ever “breaking into” a database. If the assistant can search a document collection, its effective access includes everything that collection allows it to retrieve. Enforce the applicable user and application access controls at retrieval, classify sensitive sources, and ask whether the workflow needs the data at all. “The model is private” does not answer whether the right information is being sent to the right component.

Application boundaries still matter, but they must account for the connections agents create. A workflow may cross from an enterprise application to a model provider, a vector database, a plug-in, and an external API. Each handoff is a boundary where data can be retained, transformed, or acted upon. Treat third-party connections as part of the system’s attack surface: understand what they receive, what they can do, and how their access can be withdrawn. Contract language is useful; technical limits and observable behavior are better.

Logging and recovery also remain essential. Record the chain of relevant events—the initiating user, the agent identity, retrieved sources, tools called, and actions taken—while respecting privacy and retention requirements. A log that says “assistant completed task” is not enough to reconstruct an incident. Plan how to isolate a compromised connector, model, or workflow without disabling unrelated business operations.

Find the real AI estate

The architecture on paper may not be the architecture in use. Employees may paste customer information into public chat tools, teams may build small automations with approved platforms, and suppliers may quietly add AI features to products already in the environment. These are not one category of risk, and they do not all deserve the same response. But a security leader cannot reason about exposure that remains invisible.

Start with discovery that combines several imperfect views: procurement and vendor reviews, identity and access logs, network or endpoint signals where appropriate, application inventories, and conversations with business teams. Ask what work people are trying to accomplish, not only which tools they use. A blocked tool may reappear under another name if the underlying need is ignored. Provide safer routes for common tasks, and make the rules clear about what data may be entered into which services.

Then distinguish a writing assistant that drafts low-sensitivity text from an agent that can read employee records, modify cloud resources, or send money. Risk depends less on the label “AI” than on the combination of data, authority, reach, and consequence. Trace what information the workflow can access, what actions it can initiate, which systems or people those actions can reach, and how difficult resulting harm would be to detect and reverse.

That lens avoids two expensive errors. Treating every AI feature as a crisis encourages blanket restrictions that people route around. Treating every feature as ordinary software misses workflows that combine broad data access with the ability to act. Apply deeper review where privilege, sensitive information, external exposure, or irreversible consequences accumulate. For low-impact uses, proportionate controls may be enough.

The practical exercise is architectural, not theatrical. Pick one real workflow and draw its path: user, identity, model, data sources, connectors, tools, outputs, and downstream decisions. Mark every place authority changes hands or information leaves a controlled boundary. Then ask which existing control governs that transition—and what evidence would show it is working. The fundamentals have not moved. The paths through them have.

Once a workflow’s path is visible, investment decisions become less about buying “AI security” and more about deciding where delegated work earns its keep. The useful question is not whether a system uses AI. It is whether a particular task improves enough to justify the data, permissions, failure modes, and operating cost that come with it.

Suppose the security team at Northstar Health is considering an AI assistant for alert triage. “It will make analysts more efficient” is not yet a case for investment. Which task is being improved: summarizing alerts, enriching them with context, recommending a disposition, or closing them automatically? These are different levels of authority and different risks. A summary can be wrong and still be useful if an analyst checks it. An automated closure can quietly bury the one alert that mattered. Name the work before judging the AI.

Start with a specific use case and the organization’s current process. The Delegation-and-Consequence Lens gives leaders a way to trace the task through human control, measurable change, and the authority involved. Draw on the outcome-measurement approach established earlier in the book: compare the system with a meaningful baseline, include the human work required to review or correct its output, and judge results by security outcomes rather than activity or a polished demonstration. The evaluation should reflect the workflow the organization actually intends to use. A faster task is not, by itself, a security outcome.

Then map the exposure. What information must the system see to do the job? Does it need raw incident data, or would a smaller, redacted extract suffice? Which users, repositories, and tools can it reach? Can it write, change a ticket, quarantine a device, or only recommend an action? A tool that summarizes public threat reports has a different risk profile from an agent that can query identity systems and disable accounts. Access should follow the task, not the product’s maximum capability.

The next question is how failure becomes visible. A model can produce a plausible answer that is incomplete, stale, or simply wrong. What signals reveal that—an analyst’s review, a comparison with a known-good source, a test set, an audit trail, or a downstream control that rejects unsafe actions? Who receives an alert when quality degrades? What happens when the service is unavailable, its output cannot be verified, or it behaves differently after an update? “A human is in the loop” is not a control unless that person has time, context, and authority to disagree.

Make sure the evidence fits the claim. A vendor demonstration or forecast can help frame questions, but it does not establish that the system will improve this organization’s security. Apply the evidence discipline set out earlier: distinguish claims from measured performance in the intended setting, and keep uncertainty visible while deciding whether to proceed.

That points to staged deployment. Begin with a bounded use case, restricted data, and read-only access where possible. Let the system recommend before it acts. Review its performance and the human effort needed to supervise it. Expand authority only when the evidence supports expansion. If the tool’s value depends on broad access or automatic action, that is not a reason to skip the stages. It is a reason to scrutinize them more closely. Match oversight to consequence.

Northstar might discover that the assistant produces useful summaries but adds little once analysts spend time checking every detail. Or it might find that summaries are reliable enough to shorten triage, while recommendations still need review. Either result is informative. The aim is not to prove the purchase was wise; it is to learn where the capability fits, where it does not, and what safeguards the real workflow requires.

A practical investment question, then, has four parts: Which task improves? What data and authority does the system need? How will failure be detected and contained? What comparison demonstrates value? If those answers are vague, the next investment should be in understanding the workflow—not in a larger license. AI can change the economics of security work. The leader’s job is to establish, with evidence, whether it changes them in the organization’s favor.

Once an AI capability has proved useful in a real workflow, the next question is not simply who owns the model. It is who owns the work the model now helps perform—and the consequences when that work goes wrong.

At Northstar, an internal service agent reads equipment-support tickets, checks maintenance records, and can request replacement parts. The security team protects the platform. The IT team operates it. Clinical operations defines the process. Privacy reviews the information it handles. Legal advises on obligations. But if the agent orders a replacement for the wrong recipient after following malicious instructions embedded in a ticket, “the AI did it” is not an answer. The action belongs to the business process that authorized it, even if the precise failure arose in the technology.

That distinction is the foundation of useful governance: assign responsibility to the people who can shape the workflow, while giving technical teams clear authority over the controls that make it safe.

Give the workflow an owner

Every consequential AI-enabled workflow needs a business owner who is accountable for its purpose, acceptable outcomes, and operating limits. That owner should be able to answer what decisions the system may make, what it must refer to a person, and what level of error is tolerable. The owner cannot delegate accountability to a model provider or a security review.

Technical ownership is different, but equally necessary. Product and engineering teams are responsible for how the system is built, connected, tested, monitored, and changed. Security defines and evaluates safeguards such as authentication, isolation, logging, and limits on tool access. Privacy and legal teams assess data use, retention, disclosure, and relevant obligations. These functions should influence design before deployment, not arrive as a final approval desk after the architecture has hardened.

The exact arrangement will vary. A low-impact assistant that drafts internal summaries does not need the same approval path as an agent that can alter customer records or move money. What must not vary is the clarity of the handoffs. Someone has to own the business outcome; someone has to operate the system; and someone with sufficient independence must be able to challenge whether the risk is acceptable.

Decide who may authorize action

Approval authority should follow consequence, not novelty. A model may recommend a refund, but a person may need to approve it above a defined threshold. An agent may disable a compromised account automatically within a preauthorized scope when detection is strong and the business impact is acceptable; restoring access later does not undo a clinical interruption. Actions such as deleting data or changing a production security policy may require a more deliberate path.

These boundaries need to be expressed in the workflow itself. “Human in the loop” is not a control if the human receives an opaque recommendation, has seconds to approve it, and cannot see the evidence. Meaningful review requires enough context, time, and authority to reject or pause an action. For routine, bounded operations, preapproved rules and automatic limits may be safer than a nominal approval click on every transaction.

The organization should make clear who is authorized to intervene when a workflow exceeds its intended scope. That is both an operational responsibility and a governance decision: the organization needs to know who can act and who is answerable for the limits it sets. Assistance is not autonomy: define whether the system proposes, receives approval, or can act across steps, and assign responsibility accordingly.

Make incidents everyone’s concern

An AI-related incident may look like a familiar security event—data exposure, account compromise, unauthorized change—or like a process failure: an agent repeatedly makes an incorrect decision, follows hostile content, or uses a legitimate tool in an unintended way. Response plans should cover both. A model error is not automatically a cyberattack, and a security incident is not made less serious because a model was involved.

The response team needs a route to disable the affected workflow without unnecessarily taking unrelated services offline. Business owners can judge which operations must stop and how customers or staff are affected. Engineering can isolate the agent and preserve technical evidence. Security can assess compromise and containment. Privacy and legal can evaluate notification and contractual duties. Communications and executive leadership may need to manage external consequences. The organization should agree on these roles before the first urgent call, not negotiate them while an agent continues issuing instructions.

Incident review should ask not only whether the model behaved unpredictably, but why the system allowed that behavior to have effect. Was its identity too powerful? Did untrusted input reach a privileged tool? Were logs insufficient? Was an exception approved without an expiry date? The answers often point to ordinary design and operational weaknesses made more consequential by delegated action.

Build the judgment to govern

No single new job title solves this problem. Teams need enough shared fluency to inspect an AI-enabled workflow from end to end: what information enters, how it is interpreted, which tools can be invoked, what authority those tools carry, and how the result is checked. Security professionals need to reason about model behavior without treating it as magic; engineers need to understand that a prompt is not an access-control boundary; business owners need to recognize where automation changes a decision rather than merely speeds up paperwork.

That fluency can be developed through cross-functional design reviews, scenario exercises, and practical tests of real workflows. Ask a team to trace a customer request from input to action. Introduce a misleading document or an unavailable service. See whether the agent stops safely, whether a person can intervene, and whether the resulting record is intelligible. These exercises reveal gaps that policy language alone cannot.

Governance does not replace technical controls. A committee cannot compensate for excessive permissions, missing logs, or an agent that can reach systems it does not need. Nor can technical controls decide which business risks are acceptable. Good governance connects those decisions: the business defines the purpose and tolerable consequences; technology and security enforce boundaries; oversight tests whether the arrangement still matches reality.

The useful question for leaders is not, “Who owns AI?” It is: For each AI-enabled workflow, who owns the outcome, who can authorize its actions, who can intervene, and who is prepared to explain what happened? If the answers differ across teams, governance has work to do before the next delegation becomes routine.

Those ownership questions become more useful when they are asked about actual work, not AI in the abstract. “Are we using AI responsibly?” invites a reassuring answer. A concrete question—“Which systems can this agent change, and who reviews those changes?”—creates something leaders can verify.

The board does not need to approve every model or workflow. It does need a clear picture of where delegation changes the organization’s exposure. Questions like these can open that conversation:

• Where can AI act, rather than merely advise? Which workflows allow a model or agent to send messages, change records, run code, approve transactions, or alter security controls? What actions still require a person’s authorization?
• What can it reach? Which data, applications, credentials, and external services are available to each system? Are those permissions limited to the task, or inherited from a user or service account with broader access?
• How do we know what it did? Are actions logged in a form investigators can use? Who reviews high-impact outputs, and who can intervene if something goes wrong?
• What can an adversary now do more cheaply or quickly? Which parts of our exposure—target research, tailored deception, vulnerability discovery, or routine attack activity—could be accelerated? Which controls would still interrupt the attack?
• What evidence supports our decisions? Are claims about reduced risk or improved detection based on results in our environment, independent evaluation, observed incidents, or a supplier’s demonstration? What uncertainty remains, and what would cause us to reconsider?
• What happens when the system is wrong, manipulated, or unavailable? Is there a safe fallback and a named decision-maker?

These are not questions to recite at every meeting. Choose those that fit the decision in front of you, then follow the answers to their operational consequences. If an agent can alter a customer record, for example, ask not only whether that is useful, but what identity it uses, what evidence it leaves, how errors are detected, and who can stop it. If a team says AI has improved security, ask which outcome improved and how it was measured. A confident answer is not the same as a tested one.

At Northstar, the fictional company that has carried us through this book, the CISO does not respond by banning agents or handing them the keys. The company allows a security agent to summarize alerts and propose containment actions; it requires human approval before disruptive changes. Other uses can earn more autonomy as evidence supports it—not because a demonstration looked impressive.

That is the balance leaders are trying to achieve: room to learn, with consequences kept inside deliberate boundaries. AI does not remove the need for security judgment. It makes the quality of that judgment visible in a new way: in what the organization delegates, what it can observe, and how quickly it can take control back.