AI Agent Security Needs a Tool Boundary, Not Just Better Prompts

An AI agent that can call tools can also call the wrong one. When that happens, the question a board may ask is not only what the prompt said, but what stopped the agent from acting anyway. If the only answer is that the prompt told it not to, there is no enforceable boundary outside the model.

A prompt can guide an agent's behavior. Production approval should also depend on whether controls outside the model can limit and record what the agent does.

An InfoQ presentation by Advait Patel argues for moving the security boundary from prompts to the tool layer, using scoped workload identities and better observability ¹. It is a useful planning framework for AI agent security, but the supplied presentation description does not provide implementation details or validation results ¹.

Analysis: Treat model instructions as one layer of defense, not the boundary. Make authorization enforceable outside the model, then test whether it holds when the agent receives hostile or misleading content.

Prompts Are Not a Security Boundary

Patel's presentation, Zero Trust Agent Systems that Pass Audits and Still Ship, was published by InfoQ AI, ML & Data Engineering on November 5, 2026. It describes a production security playbook built around moving the boundary from prompts to the tool layer and using scoped workload identities for agents ¹.

An agent's instructions and its permissions serve different purposes. Instructions guide what the model is asked to do; tool authorization determines whether a requested operation is permitted. Analysis: If a tool can perform a sensitive action, a prompt asking the agent not to do it is not a substitute for an external control that denies the action.

The presentation also discusses prompt injection through tool outputs, audit-ready observability, and kill switches intended to protect critical data ¹. These topics suggest an operating model: constrain what the agent can reach, treat external content as potentially hostile, and retain evidence of relevant decisions.

The source is a presentation, not an independent evaluation. Its supplied description does not report testing or results in a specific production environment ¹. Use it to define review questions and validation work, not as proof that a design is secure.

What a Tool-Layer Access Review Must Inspect

Start with the tool, not the prompt. For every tool available to an agent, document what it can read, change, export, or administer; which identity calls it; and which conditions should cause a request to be denied. This is a practical interpretation of the presentation's proposed shift toward tool-layer controls, not a configuration standard specified by the source ¹.

Map each agent task to permitted tools and actions. Where the underlying system allows it, split read, write, delete, export, and administrative permissions instead of granting one broad capability that covers them all. Analysis: Narrower permission categories can make it easier to determine after the fact whether an agent was authorized to perform a particular operation.

Run the enforcement path through these questions:

• Are tool arguments checked before execution?
• Are target records, destinations, and data types constrained?
• Can a high-impact action require an additional approval step?
• Does an unapproved tool call fail outside the model, even if the agent requests it confidently?

These are deployment checks drawn from the presentation's focus on the tool layer. The supplied description reports no specific settings or test results for them ¹.

For every permission, test the matching denial: an unapproved tool, action, resource, or data transfer. Record the attempted request and the enforcement outcome. A refusal in the model's text is not enough; the test should establish whether the operation proceeded. For a related look at gating agent roles in multi-agent systems, see Role Contracts Need a Gate: Enforcing Boundaries in Black-Box Multi-Agent Systems.

Agent Workload Identity: Scoping Permissions per Workflow

The presentation proposes scoped workload identities as part of its security approach ¹. As an implementation recommendation, each agent or workflow can access tools under its own workload identity, with permissions tied to its assigned function rather than a credential shared across tasks.

For each identity, record its owner, purpose, permitted tools and actions, and revocation path. Define how it is issued, how credentials are protected, how rotation works, and who can revoke access when the agent, workflow, or connected tool changes. These are implementation recommendations; the presentation summary does not specify an identity lifecycle ¹.

Analysis: A broad credential shared across unrelated tasks can make it harder to identify which workload acted and what access to revoke during an incident. Task-specific identities can provide a clearer unit for authorization and containment, provided their permissions are genuinely scoped and their use is traceable in logs.

Set a deployment gate: do not issue a production identity until its owner and permissions are documented and its rotation and emergency-revocation paths are defined and exercised. Without these records and tests, it may be harder for a platform team to establish who or what can act through the agent.

Prompt Injection Defenses: Testing Hostile Tool Output

Treat every tool response as untrusted input. The presentation identifies prompt injection through tool outputs as a threat, but the supplied description offers no complete mitigation design or test results ¹.

Build pre-production cases where a tool response contains instructions to ignore policy, disclose sensitive information, invoke another tool, change a destination, or misstate what an operation did. These are proposed test cases, not incidents reported by the source.

Also test plausible but unreliable responses: incomplete records, contradictory fields, or content designed to redirect the workflow. The relevant question is not whether the agent repeats hostile text, but whether processing that text can trigger a prohibited tool call or unauthorized data transfer.

For each case, check whether the agent separates returned data from instructions, whether sensitive values are withheld from later calls, and whether the authorization layer still blocks prohibited actions. Preserve the injected content, the agent's proposed action, the authorization result, any follow-on tool call, and the retained evidence.

Analysis: A test should pass only if the expected control holds at the enforcement layer. If the agent says it will ignore an instruction but the tool call still runs, the protection has not been demonstrated. The source describes the threat but reports no validated results, so this testing has to happen in the deploying organization's environment ¹. The broader question of what counts as proof an agent works is explored in Legora Says It Can't Read Client Traces—What Counts as Proof a Legal AI Agent Works?.

AI Agent Audit Logs: What Audit-Ready Evidence Looks Like

The presentation calls for audit-ready observability ¹. For a team, that can mean reconstructing why a material tool call happened and whether it was allowed, rather than relying only on a transcript of what the model said.

Capture, at minimum: workload identity, agent or workflow context, tool name, requested operation, target resource, authorization decision, policy version, timestamp, and resulting status. The source does not list these fields; they are practical additions intended to make its observability goal reviewable ¹.

Keep enough request and response context to investigate tool-output injection after the fact. Reviewers may need to determine whether a tool response carried hostile content and whether it shaped a later request. Set retention, access, redaction, and integrity rules for records that may contain sensitive inputs or outputs. These are design decisions for the deploying organization; the presentation does not detail them.

Run a reconstruction exercise using only the records the production system actually keeps. Choose a completed workflow and ask: which identity made each call, what resource did it touch, which policy allowed or denied it, and what happened next? If those questions cannot be answered from retained evidence, the observability design may need improvement.

Kill Switches: Scope and Limits

Patel's presentation discusses kill switches intended to protect critical data while keeping deployment fast and compliant ¹. The supplied description does not explain how those switches work, what they cover, or which compliance requirements are in scope ¹. A kill switch is a containment mechanism to design and test, not a substitute for ordinary authorization.

Decide what each switch disables: one agent, one workload identity, one tool, a class of action, or a whole deployment. Specify who can activate it, what approval it requires, how quickly it takes effect, and what evidence activation generates. These are implementation questions the source does not answer.

Exercise both prevention and recovery. Confirm new calls are blocked, queued or running work is handled according to policy, and an authorized operator can restore service safely. Agents that outlive a single model call make this harder; see Durable Coordination for Agents That Outlive One Model Call. Tie the switch to a business decision: which data or operations justify immediate shutdown, and when is narrower isolation the better choice?

Comparing Prompt Defenses with Enforcement Controls

Analysis: These layers do different jobs. Prompts guide behavior. Authorization determines whether an operation can proceed. Observability and emergency controls support investigation and containment. None substitutes for the others.

Control layer	What it can influence	What it cannot guarantee	Evidence to inspect
System prompts and agent instructions	The behavior the model is asked to follow	That a tool request will be denied when the model asks for a prohibited action	Relevant instructions and test cases involving conflicting tool output
Tool authorization and workload identity	Which identity can request which operation on which resource	That every hostile or misleading response will be recognized by the agent	Identity permissions, policy decisions, denied-action tests
Observability and kill switches	Investigation and interruption of agent activity	Least-privilege access or correct behavior before a control is invoked	Reconstructed workflows, activation records, containment exercises

The presentation supports moving toward tool-layer controls, scoped identities, observability, and kill switches. This table separates their roles for planning purposes; it is not a set of results the source demonstrates ¹.

Production approval should rest on evidence such as denied-action tests, an identity review, hostile-output tests, a successful audit reconstruction, and an exercised emergency control. That is recommended practice, not an outcome the presentation establishes ¹.

Secure AI Agents in Production: Before Approval

Name an owner for each tool, workload identity, policy, log stream, and emergency control. Relevant owners may come from security, platform engineering, application teams, and incident response.

Build a control register covering the agent's purpose, approved tools and actions, workload identity, sensitive data paths, logging fields, and emergency controls. Treat missing owners, unclear permissions, and untested revocation paths as blockers rather than notes for later. Controls on the model call itself, such as those an enterprise AI gateway can provide (routing constraints, spend controls, audit logs), are a separate layer and do not replace tool-layer authorization.

Run negative authorization tests and hostile-output tests in pre-production. Preserve the inputs, policy decisions, and outcomes. Then reconstruct a full workflow using only the evidence the production system will retain, and address any gaps the exercise reveals.

The presentation offers a planning framework, not independent validation ¹. Before relying on any control, test it against your own tools, identities, policies, and failure paths; schedule the first hostile-output test before the first production rollout.

Sources

¹ Presentation: Zero Trust Agent Systems that Pass Audits and Still Ship, InfoQ AI, ML & Data Engineering, published November 5, 2026. https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/