What CISOs need to know about tool-using AI agents

Tool-using agents change the CISO’s unit of analysis. The risk is not simply that a model may produce incorrect text. It is that untrusted content can influence a probabilistic planner that holds credentials, reads private data and invokes systems with real consequences.

That chain can cross model providers, retrieval services, browsers, enterprise applications, code runners and human approval interfaces. Security review must therefore follow identities, data and actions across the workflow. Model testing is one input, not the security boundary.

Draw the action path before debating controls

Map the agent from input to effect. Identify every place instructions can enter: user messages, retrieved documents, email, web pages, tool output, memory and agent-to-agent messages. Then list the data the system can observe, the credentials it can obtain and the state each tool can change.

Mark trust transitions and enforcement points. A useful diagram distinguishes model suggestions from authorisation decisions and actual execution. If a natural-language response determines access without a separate policy control, the model has become a security boundary it was not designed to be.

The NIST generative AI profile addresses risks across governance, content provenance, information security and incident handling. For a tool-using agent, those concerns meet in one action path.

Give the agent its own identity and a narrow mandate

Do not let an agent borrow a developer’s credentials or operate through a shared account that erases attribution. Use workload identity, short-lived credentials and scopes aligned to the evaluated task. Preserve the initiating user or service mandate where downstream policy depends on it.

Least privilege is more than restricting API verbs. Constrain resources, tenants, transaction values, destinations and duration. Separate read, propose and execute capabilities. Require fresh confirmation for high-impact actions rather than interpreting a general instruction as permanent consent.

Revocation must propagate. If the user loses access or the agent is suspended, cached credentials and queued work should not continue exercising yesterday’s authority.

Treat untrusted content as hostile control input

Prompt injection is dangerous because data and instructions share a channel. A retrieved document can contain text aimed at the agent; a compromised tool can return a plausible instruction; a website can attempt to redirect a computer-use workflow.

The security objective is not to make the model perfectly distinguish good instructions. It is to prevent content from expanding authority. Keep system rules outside retrieved data, label provenance, minimise exposed secrets, validate tool arguments and enforce action policy after the model proposes a call.

Test combinations, not isolated defences. Use cases where private context, hostile content and an external tool are present together. Check the resulting state and data flow, including attempts that the enforcement layer blocked.

Separate containment from permission

Authorisation and sandboxing answer different questions. Authorisation asks whether this identity may take this action on this resource. A sandbox asks what executed code or browser activity can reach and consume. An authorised task can still run malicious code; a well-contained process can still make an unauthorised business change through an allowed API.

For code or computer-use agents, constrain filesystem mounts, network egress, process privileges, secrets, persistence and resource consumption. For business tools, enforce tenant boundaries, object-level policy, confirmation and rate or value limits. Test the real production configuration rather than a safer demonstration environment.

The UK NCSC guidance treats secure design, development, deployment and operation as connected responsibilities. Agent controls fail when they cover only one layer.

Bring the agent into secure delivery and supply-chain practice

Prompts, tool schemas, policy files, evaluation cases and orchestration code are release artefacts. Protect their repositories, review changes and bind evaluation results to versions. Inventory model, plugin, connector, container and package dependencies, including hosted services that can change without a local deployment.

The NIST Secure Software Development Framework gives producers and acquirers a common language for secure development outcomes. Extend that discipline to agent-specific configuration. A model swap or changed tool description can be behaviorally material even when the application code is unchanged.

Require suppliers to describe update channels, vulnerability handling, logging, tenancy and deletion. A security questionnaire without evidence—sample logs, architectural boundaries, test results or contractual commitments—does not establish the control.

Instrument for investigation and containment

Record the authenticated initiator, agent/version, policy decision, relevant context references, tool call, arguments or protected digest, execution result, external state change and human intervention. Minimise sensitive content and separate operational telemetry from broad transcript retention.

Alerts should correspond to attack paths: blocked cross-tenant access, unusual tool sequence, unexpected destination, repeated authorisation failure, privilege change, large outbound transfer, policy bypass or loss of trace continuity. Each needs a response owner and playbook.

Test containment by revoking credentials, disabling one capability, isolating a runtime and stopping queued work. Confirm what happens to partial external actions. A “kill switch” that stops new prompts but leaves active jobs and tokens alive is incomplete.

Prepare for incidents that do not look like model failures

An agent incident may first appear as an incorrect transaction, data disclosure, compromised connector, supply-chain change or insider misuse. Integrate it with established cyber and operational response rather than building an AI-only lane.

NIST SP 800-61 Rev. 3 emphasizes incorporating incident response across cybersecurity risk management. Preserve configuration, identities, policy decisions, tool traces and affected state so responders can reconstruct cause and scope. Define provider escalation, customer communication and return-to-service criteria before release.

The CISO’s most useful question is not “Is the model secure?” It is “Can untrusted influence cross our controls and cause an unauthorised effect?” Mapping and testing that path turns an ambiguous AI concern into security engineering.

Review one compound attack, end to end

Suppose a finance agent reads invoices from a mailbox, retrieves purchase-order data and drafts a payment instruction. A malicious attachment tells the agent that the supplier has changed bank details and directs it to a lookalike portal. The individual components may behave as designed: email delivered the file, retrieval found an order and the browser opened a site. The security failure emerges from their composition.

Test the workflow in layers. First, verify that attachment content cannot override system policy. Next, confirm the agent cannot retrieve secrets unrelated to the invoice. Then check whether the payment tool independently validates supplier identity, approved bank details, amount and user mandate. Test that new destinations require a separate authenticated process. Finally, observe whether the sequence produces a useful signal before an irreversible action.

Run the case with realistic production permissions and again with one control deliberately removed. That reveals which layer actually prevents loss and whether teams have mistaken defence in depth for duplicated policy text. Record blocked attempts as evidence; a secure outcome may be a refusal or handoff rather than task completion.

The exercise also clarifies ownership. Messaging security handles the attachment channel, identity controls the workload principal, the application team owns transaction enforcement, and security operations investigates the trace. The workflow owner remains accountable for the business process. A CISO can challenge this system precisely because the path and responsibilities are explicit.

Repeat the review after a meaningful architectural change and after a real near miss. Attack paths evolve when tools, providers, memory or user populations change. A threat model should be versioned with the system and connected to regression cases, not treated as a pre-launch workshop that permanently blesses the design.

Tool-using agents become governable security systems when the path from hostile influence to real effect is visible, bounded and repeatedly tested. That path—not the model label—is the CISO’s control surface.