Prompt-level controls only inspect content, while agentic systems create risk through tool use, workflow triggering, and downstream execution. Once an agent can act, security must govern identity, access scope, and runtime behaviour, because the real exposure comes from what the system can do, not only what it says.
Why This Matters for Security Teams
Prompt-level security can filter unsafe text, but agentic systems fail in different ways: they invoke tools, chain workflows, and execute actions that outlive the original prompt. That shifts the risk from content moderation to authority management. The practical lesson is that an agent with broad tool access can cause damage even when every prompt looks benign. NIST’s NIST AI Risk Management Framework treats these as lifecycle risks, not prompt-only events, and NHIMG research on the OWASP Agentic Applications Top 10 shows why the attack surface expands once an AI can act. The core mistake is assuming the model is the boundary; in practice, the boundary is the identity, permissions, and runtime policy behind every tool call. In practice, many security teams encounter this only after an agent has already read, sent, or changed something it was never meant to touch.
How It Works in Practice
Agentic security needs controls that evaluate what the system is trying to do at the moment it tries to do it. Static RBAC alone is too coarse because agent behaviour is dynamic: the same agent may summarize data in one step, query a database in the next, and trigger a ticketing workflow after that. The better pattern is intent-aware authorization plus short-lived credentials that are issued only for the task at hand. That means treating the agent as a workload identity, not as a person, and binding its actions to cryptographic proof of who or what it is. Standards and implementation guidance from OWASP Top 10 for Agentic Applications 2026, CSA MAESTRO agentic AI threat modeling framework, and the AI Agents: The New Attack Surface report point in the same direction: evaluate policy at runtime, minimize standing privilege, and log every tool invocation.
- Issue ephemeral secrets per task, then revoke them when the task completes.
- Use workload identity mechanisms such as SPIFFE, SPIRE, or OIDC-backed service identities for the agent runtime.
- Apply policy-as-code at request time, using context such as tool, data sensitivity, destination, and user intent.
- Constrain high-risk actions with human approval or step-up checks when the workflow crosses trust boundaries.
This is especially important where agents can call external APIs, shell commands, or internal systems without a reliable human-in-the-loop. These controls tend to break down in long-lived autonomous loops because the agent can accumulate context, chain permissions, and trigger downstream actions faster than static access reviews can react.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance safety against latency, developer friction, and workflow fragility. That tradeoff is real, and current guidance suggests there is no universal standard for every agent pattern yet. A customer-support agent that drafts replies has very different risk than a code agent that can deploy changes or a finance agent that can move records between systems. The former may only need constrained read access, while the latter may need ephemeral write privileges, scoped approvals, and stronger auditability.
Edge cases appear when teams mix human and agent actions in the same session, reuse long-lived API keys, or grant agents broad service account access to “avoid breakage.” Those shortcuts create exactly the persistent privilege that autonomous systems should not have. NHIMG’s coverage of the CoPhish OAuth Token Theft via Copilot Studio and the Amazon Q AI Coding Agent Compromised cases show how quickly tool access becomes execution risk. Best practice is evolving, but the direction is clear: govern the agent’s identity, constrain its runtime authority, and assume prompt filters alone will not stop harmful actions once execution is possible.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic attacks exploit tool use and workflow abuse beyond prompt content. |
| CSA MAESTRO | TRM | MAESTRO focuses on threat modeling autonomous agent behaviour and tool chains. |
| NIST AI RMF | AI RMF covers governance for autonomous system risks across the full lifecycle. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Agent workloads need short-lived identities and secret rotation, not static credentials. |
| NIST Zero Trust (SP 800-207) | 4.2 | Zero trust requires continuous verification for each agent request and action. |
Use AI RMF governance to assign ownership, monitor runtime behavior, and document residual risk.
Related resources from NHI Mgmt Group
- Why do agentic AI systems require different controls from LLM applications?
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
