TL;DR: Agent frameworks such as AWS Strands expand risk from model outputs to tool calls, data access, and multi-step actions, and ActiveFence shows why input and output filtering alone cannot stop confused-deputy failures or sensitive data leaks. Runtime guardrails move policy enforcement into the agent lifecycle, which makes agent governance a continuous control problem, not a one-time prompt problem.
At a glance
What this is: ActiveFence argues that AWS Strands agents need runtime guardrails because filtering prompts and outputs alone does not stop unsafe tool use or data exposure.
Why it matters: This matters to IAM and NHI practitioners because agent governance has to control action, privilege, and data access at execution time, not just at the model boundary.
Context
Agentic systems are changing from text generators into software that can call tools, query data, and chain actions across a workflow. That shift creates a governance gap because traditional controls were built for single-turn input and output checks, not for runtime decisions inside an agent session.
In identity terms, the risk is not just what the model says, but what the agent is allowed to do on behalf of a user or system. When a legitimate tool invocation can produce an unauthorized outcome, the control problem moves into privilege scope, policy enforcement, and continuous verification.
The article's example is typical of the broader agentic risk pattern: the request appears normal, the tool call is valid, and the failure only becomes visible at the point of data exposure.
Key questions
Q: What breaks when runtime guardrails are missing for agents?
A: The system loses the ability to stop unsafe inputs before they influence reasoning, block dangerous tool use before execution, and prevent sensitive outputs from reaching users. Without those checks, a legitimate request can be converted into an access event, and policy violations appear as normal behaviour.
Q: Why do authenticated users still create risk for agentic tool access?
A: Authentication only proves who entered the session, not whether the requested action fits the user's intent or entitlement. In agentic systems, a legitimate user can still induce the agent to overreach if the tool policy is broader than the task. That is why authorisation must be evaluated at execution time, not assumed from login state.
Q: What signs show that agent guardrails are not working?
A: The warning signs are repeated secret detections, unexplained outbound communication, and developers disabling controls because they are too hard to use. If the same agent behavior keeps creating incidents, the controls are advisory rather than enforced. Effective guardrails should change default behavior without needing constant human intervention.
Q: How should security teams compare runtime guardrails with prompt filtering?
A: Prompt filtering changes the text that enters or leaves the model, while runtime guardrails govern what the agent is allowed to do as it runs. The first reduces unsafe content, but the second controls action, privilege, and data flow. For agent security, those are complementary controls, not substitutes.
Technical breakdown
Why prompt filtering fails in agentic tool chains
Prompt filtering assumes a single request-response boundary, but agent frameworks like AWS Strands operate across multiple stages. A user input can be safe on its face while still steering the agent toward a harmful tool call or an overly broad data query. The model may also combine benign steps into an unsafe outcome through multi-step reasoning. That means the control problem is not only content moderation, but governance of the entire execution path. For security teams, the key distinction is between controlling text and controlling action.
Practical implication: move policy checks from the prompt edge into the full agent execution path.
Runtime guardrails as an enforcement layer
Runtime guardrails sit alongside the agent lifecycle and inspect inputs before reasoning, tool calls before execution, and outputs before delivery. In practice, that means the enforcement point is external to the model rather than embedded in it. This is important because a model can produce a plausible answer while still driving an unsafe action, and a tool call can be syntactically valid while still violating policy. Runtime controls therefore act more like a decision layer than a filter, with allow, block, or modify outcomes based on context.
Practical implication: design agent controls so policy decisions can intercept both tool invocation and response release.
Confused deputy risk in agent frameworks
The confused deputy problem occurs when a system with legitimate access is manipulated into using that access for the wrong principal. In agentic systems, that often shows up when a user request is technically authenticated, but the agent is still induced to retrieve or expose data outside the intended purpose. This is a governance failure, not a classic exploit. The agent is doing what it was allowed to do, just for the wrong outcome. That creates a direct intersection with identity, privilege, and delegated authority management.
Practical implication: bind agent permissions to task scope and user intent, not just to session authentication.
Threat narrative
Attacker objective: The attacker wants the agent to disclose data or perform actions that exceed the user's legitimate scope while staying within valid tool and session permissions.
- Entry occurs through an authenticated but apparently benign user request that reaches the agent with enough context to shape tool selection.
- Credentialed access to internal tools lets the agent query customer records or transaction history using a valid account identifier.
- The agent returns sensitive data because the tool call is legitimate, but the policy context was never checked at execution time.
- Impact is unauthorized disclosure of internal or regulated data through a confused-deputy path rather than a traditional exploit.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime enforcement is now a governance requirement for agentic systems: agent risk is not contained at the model boundary, because the real control point is the moment an action is taken. When agents can call tools and fetch data, policy must be evaluated continuously, not assumed from the prompt or the session. Practitioners should treat the execution layer as the primary control plane.
Confused-deputy failures expose a delegated-authority gap, not a model defect: the article's banking example succeeds because the agent is trusted to act, yet the request origin is insufficient to determine whether the action is appropriate. That is an identity and privilege problem wrapped inside an AI workflow. The named concept here is agent runtime trust gap: the mismatch between authenticated access and authorized intent. Practitioners should govern that gap explicitly.
Agent guardrails should be assessed like any other policy engine: if the enforcement layer cannot inspect inputs, tool calls, and outputs in sequence, then it cannot be relied on as a control. This puts observability, decision logging, and exception handling on the same level as access policy. Teams should expect runtime guardrails to become part of standard identity and security architecture, not an optional add-on.
Reusable guardrails will matter more than framework-specific fixes: the article points to a pattern that can apply across agent frameworks, which means governance maturity will increasingly depend on policy portability. That is particularly relevant where multiple agent stacks share internal tools or data sources. Practitioners should plan for consistent enforcement across agent platforms, not isolated point solutions.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Agent runtime trust gap: the central governance problem is no longer whether a model can generate harmful text, but whether an authenticated session can be turned into an unauthorized action. That shifts control ownership toward execution-time policy, auditability, and delegated authority management.
The operational takeaway for practitioners is that guardrails have to sit where the agent touches tools and data, not where users type prompts. If your programme cannot observe or intervene at that point, you do not yet have agent governance, only content moderation.
Third-party access becomes a sharper issue as agent ecosystems expand. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
For practitioners
- Implement runtime policy checks for agent execution Validate user inputs, tool calls, and generated outputs before they can influence data access or external actions. Treat allow, block, and modify decisions as part of the agent lifecycle rather than as a post-processing step.
- Constrain delegated tool scope by task Limit each agent to the smallest set of tools, datasets, and parameters required for the current task so authenticated sessions cannot drift into broader data retrieval.
- Log policy decisions at each enforcement point Record what was inspected, what was allowed, what was blocked, and why so the security team can reconstruct agent behaviour after a sensitive interaction.
- Test for confused-deputy behaviour in red team exercises Use scenarios where a benign-looking request should not be enough to trigger privileged data access, and verify that the agent refuses or masks the response.
- Separate user authentication from action authorisation Require explicit policy evaluation at tool invocation time so a valid login does not automatically become permission to retrieve regulated or high-sensitivity data.
Key takeaways
- Agentic tool use expands the security problem from content moderation to action control, because a valid request can still produce an invalid outcome.
- The confused-deputy pattern matters here because the agent acts with legitimate access, even when the resulting data exposure is not authorised by intent.
- Runtime guardrails are the control that changes the outcome, but only if they can inspect and stop inputs, tool calls, and outputs before exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent tool misuse here is fundamentally about overreach through delegated privilege. |
| ASI02 — Tool Misuse | The article centers on validating and constraining tool calls during execution. | |
| ASI09 — Human-Agent Trust Exploitation | The confused-deputy example depends on users leveraging the agent's trusted position. | |
| Recommendation — Apply ASI03-style controls to bind agent actions to explicit privilege and intent boundaries. Inspect and restrict tool invocation paths so the agent cannot use tools outside approved policy. Design controls that prevent user prompts from being converted into unwarranted trusted actions. | ||
| NIST AI RMF | MANAGE — AI Risk Management | Runtime guardrails are a direct risk management control for production agent behaviour. |
| Recommendation — Embed runtime control checks into AI operations and escalation handling under MANAGE. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The exposure path can lead to sensitive data access through legitimate sessions and tools. |
| Recommendation — Map agent misuse scenarios to credential-access paths and monitor for overbroad data retrieval. | ||
Key terms
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
- Agentic Tool Authority: Agentic tool authority is the effective power an AI agent has through the tools, APIs, and services it can invoke. It matters because a low-privilege role can still become high impact if the agent can use tools to change state, move data, or trigger downstream actions.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps practitioners align delegated access, runtime control, and lifecycle governance across modern identity programmes.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org