An execution-boundary review for tool-using agents. NIST terminology, versioned CaMeL and agent-security research, and Bedrock documentation inform a concrete policy model without claiming universal prompt-injection prevention.
At a glance
Key findings
- A prompt-injection defense must consider tool arguments and data destinations, not only whether the model changes its stated plan.
- A content detector and an execution policy serve different purposes. Consequential actions need enforceable authorization outside model-generated prose.
- Research defenses have explicit assumptions and limits. Preserve those limits instead of describing prompt injection as a solved problem.
Follow the untrusted value into the action
Imagine a hypothetical assistant that prepares a support attachment and sends it to an approved customer contact. It retrieves a ticket, extracts an account identifier, finds the attachment, and selects a recipient. The overall sequence can remain unchanged while an untrusted value steers the result toward the wrong account or destination. Reviewing only the list of tool names would miss that possibility.
NIST's adversarial machine-learning taxonomy supplies terminology for attacks and mitigations, while the CaMeL research paper examines the distinction between control flow and data flow in agent systems. That distinction is useful for a practical review: ask both which actions can occur and which values can determine their targets. [1][2]
For each value used by a consequential tool, record where it came from and what it is allowed to influence. A recipient from an authenticated customer record has a different role from an address found in an arbitrary document. The model may help interpret the latter, but interpretation does not establish permission to send protected material there. This is an editorial design requirement, not a measured claim about an implemented agent.
Separate detection from permission to execute
A detector can flag suspicious content before it reaches a model. An execution policy decides whether a proposed action is permitted. These are complementary decisions, and their evidence should not be confused. A detector's approval is not proof that a particular file may be shared with a particular person.
Amazon Bedrock documents prompt-attack filtering and the use of input tags to distinguish the content being evaluated from developer-provided instructions. That scope matters: a reviewer should establish which content the application actually submits to the filter. The documented feature does not remove the need for downstream business authorization. [3]
In the proposed support workflow, the sender tool should still check the account, attachment classification, recipient, and requesting identity. It should perform those checks even if a detector reported no problem and even if the model describes the operation as harmless. Otherwise a statistical assessment of text has quietly become authority to perform an external action.
A proposed action still needs authorization
Check the operation, target, recipient, and caller at the execution boundary, even when the model's plan appears unchanged.
Source. NIST terminology, CaMeL v2, Bedrock Guardrails documentation, and agent design-pattern research [1]-[4].
Method. Original proposed execution-boundary diagram. It does not reproduce CaMeL's implementation or claim its formal properties. Table rows are review questions, not experimental results.
Accessible table and figure data
| Input or decision | Trusted evidence | Boundary to test |
|---|---|---|
| User intent | Authenticated request | Untrusted content does not replace the user's task |
| Retrieved value | Provenance of the source | An extracted value is not treated as authority |
| Tool operation | Allowed workflow | An unavailable operation cannot be requested indirectly |
| Resource and recipient | Ownership and sharing policy | Valid syntax does not bypass authorization |
| Approval | Specific displayed action | Changed arguments require a new decision |
| Execution | Authorized tool request | Denied requests produce no side effect |
| Input or decision | Trusted evidence | Boundary to test |
|---|---|---|
| User intent | Authenticated request | Untrusted content does not replace the user's task |
| Retrieved value | Provenance of the source | An extracted value is not treated as authority |
| Tool operation | Allowed workflow | An unavailable operation cannot be requested indirectly |
| Resource and recipient | Ownership and sharing policy | Valid syntax does not bypass authorization |
| Approval | Specific displayed action | Changed arguments require a new decision |
| Execution | Authorized tool request | Denied requests produce no side effect |
Protect the plan and the arguments separately
CaMeL explores a design that separates trusted planning from processing untrusted content and associates values with provenance and capability information. Its interpreter uses explicit security policies when tools are called. The research also explains why preventing changes to the action sequence alone can leave dangerous argument manipulation unresolved. [2]
That does not mean every application should adopt a research interpreter. The practical question is which parts of the application can enforce the required boundary without relying on the model to remember it. A narrow tool with a well-defined destination policy may need a different design from a general assistant that can browse, write files, and contact many services.
Describe the selected enforcement mechanism precisely. If it only restricts tool names, say so. If it checks resource ownership or permitted recipients, identify the trusted source for those facts. If it tracks where data originated, explain which transformations preserve that tracking. Avoid claiming information-flow guarantees unless the actual implementation and assumptions support them.
Make the tool policy concrete enough to reject an action
An instruction to use tools safely is too vague to serve as an execution contract. Define permitted operations, resources, destinations, and amounts of authority in terms that the application can evaluate. Typed arguments help identify malformed requests, but a well-formed request can still target the wrong tenant or exceed the caller's permission.
The design-pattern research on securing agents provides several approaches with different assumptions and tradeoffs. Use that work to choose a boundary suited to the task, not to collect an impressive list of defenses. A constrained workflow can deliberately offer fewer capabilities if those capabilities cover the intended job and can be checked reliably. [4]
For the support example, an editorial policy sketch might permit sending only an attachment belonging to the current account to a contact verified for that account. A different request would require a separately authorized workflow. The sketch is intentionally narrow. It shows the decision that must exist without pretending that an example policy has been deployed or proven complete.
Make human approval informative rather than automatic
Some tasks need a person to resolve ambiguity or authorize a disclosure. A useful confirmation shows the actual resource, destination, operation, and consequence. It should not ask someone to approve a summary that omits the data being transferred. Bind the approval to the action that will run, and require a new decision if a material argument changes.
Research discussions of agent defenses acknowledge intervention and usability tradeoffs. CaMeL's analysis includes declassification and user-fatigue concerns; the broader design-pattern paper also treats restrictions as choices with consequences for utility. Preserve those limits when recommending approval steps. More prompts do not automatically mean more meaningful control. [2][4]
For repetitive work, consider whether the policy can make a narrow decision automatically using trusted facts. Reserve confirmation for cases where the person has information or authority that the application lacks. Also provide a clear refusal path. A workflow that pressures the user to broaden access whenever a tool is blocked can undermine the boundary it appears to present.
Test action outcomes instead of reassuring responses
A defensive test should inspect what the agent attempted and what the execution layer allowed. Use harmless synthetic documents that contain conflicting instructions or misleading recipient information. Then verify the expected permitted action, the denied action, and the absence of unintended side effects. A polite final message is not sufficient evidence if a tool already performed the wrong operation. Capture the proposed arguments and the final authorized arguments separately, using synthetic identifiers, so an unexpected transformation is visible in the test record.
Include normal tasks in the same fixture. A boundary that blocks every request would prevent some attacks but fail the application. Record task completion, denials, clarification requests, and the policy decisions behind them without turning a small test set into a general effectiveness percentage. If testing is limited to one workflow or one input type, state that scope explicitly.
No such test was run for this article. The proposed release receipt would identify the agent version, tool schema, policy version, synthetic inputs, expected actions, actual actions, and unresolved cases. The lasting design objective is modest and concrete: untrusted content may inform a computation, but it should not acquire authority merely because a language model passes it to a tool.
Method and provenance
Review of primary standards, research, and service documentation on August 28, 2026. The support workflow, diagram, and acceptance cases are original illustrative designs.
No agent was implemented, attacked, or benchmarked. Research properties are limited by their stated threat models. The article does not claim prompt injection is solved or that a proposed policy is complete.
AI assistance. AI assistance was used to research sources, draft and structure the article, and prepare the visual specification. No human technical review is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- NIST AI 100-2 E2025 Adversarial Machine Learning taxonomy NIST. Published . Accessed .
- Defeating Prompt Injections by Design, version 2 Debenedetti and colleagues. Published . Accessed .
- Detect prompt attacks with Amazon Bedrock Guardrails AWS. Accessed .
- Design Patterns for Securing LLM Agents against Prompt Injections, version 1 Beurer-Kellner and colleagues. Published . Accessed .