System-level measurement hides the difference between low-risk and high-risk actions inside the same application. An agent that can read data, change records, and trigger transactions looks identical in a coarse inventory, even though each action carries a different governance requirement and blast radius.
Why This Matters for Security Teams
System-level measurement creates a false sense of control because it treats one agentic application as one security posture, even when the underlying agent can perform very different actions. That misses the real question: what can the agent read, change, approve, or trigger at runtime? Current guidance suggests that coarse inventories are useful for discovery, but not for authorisation, because agent behaviour is dynamic and context-dependent. The OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to this gap: risk is not just the system, it is the action pathway.
This is why NHI governance, workload identity, and action-level policy matter. A single AI agent may have permission to inspect records, but not to alter them or initiate transactions. If measurement stops at the system boundary, teams can miss privilege concentration inside one “approved” workload. NHI research on OWASP NHI Top 10 shows that agentic systems often fail at the identity and access layer first, not at the application label. In practice, many security teams encounter privilege abuse only after the agent has already chained tools or touched data beyond its intended scope.
How It Works in Practice
The safer model is to measure agent posture at the action and context level, not only at deployment time. That means separating the agent’s identity from the permissions attached to each task. A system may be tagged “low risk,” but the agent inside it could still have access to secrets, customer data, or payment workflows. For autonomous workloads, static role-based access control is often too blunt because the same agent can legitimately perform low-risk and high-risk actions in the same session.
Practitioners are moving toward intent-based authorisation, just-in-time credentialing, and workload identity. In this model, the agent proves what it is with a cryptographic identity such as SPIFFE/SPIRE or OIDC, then requests short-lived access only for the task it is currently executing. Policies are evaluated at request time, using current context such as user approval, data sensitivity, destination service, and transaction type. That approach aligns with OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise runtime governance rather than static trust.
- Inventory the agent’s actions, not just the application name.
- Classify each tool call by blast radius, data sensitivity, and transaction impact.
- Issue ephemeral secrets with narrow TTLs, then revoke them automatically after task completion.
- Evaluate policy in real time so an allowed read does not become an implied write.
- Log decision context, not only success or failure, for forensic review.
This guidance tends to break down in environments where agents share broad service accounts or where legacy workflows cannot support per-action policy evaluation because the permission model is already too coarse.
Common Variations and Edge Cases
Tighter action-level control often increases operational overhead, so organisations have to balance precision against latency, complexity, and user friction. That tradeoff is real: if every step requires human approval, the agent loses much of its value; if every step is pre-approved at the system level, posture becomes too vague to manage. Best practice is evolving, but there is no universal standard for when to use static gating versus runtime approval.
One common edge case is multi-agent workflows, where one agent plans, another retrieves data, and a third executes changes. System-level measurement may rate the whole pipeline as “approved,” yet the dangerous step is the handoff between agents. Another is read-only agents that later gain write authority through chained tools or delegated credentials. NHIMG research on AI LLM hijack breach and LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how quickly abused credentials can convert a seemingly normal system into an attacker-controlled workflow.
Another issue is secrets sprawl. If an agent can discover, cache, or reuse tokens, system-level posture will understate exposure because the real risk sits in the credentials, not the container image. The The State of Secrets in AppSec research highlights how fragmented secrets management already undermines control; in agentic environments, that fragmentation becomes an execution risk. In practice, coarse posture breaks down fastest when one agent can combine retrieval, reasoning, and execution in a single session.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AI-03 | Agentic systems need action-level risk controls, not system-only labels. |
| CSA MAESTRO | AM-02 | MAESTRO focuses on threat modeling agent workflows and tool chains. |
| NIST AI RMF | AI RMF governance requires context-aware measurement of operational AI risk. |
Use AI RMF to define action-level controls, owners, and monitoring for each agent capability.
