AI frameworks often sit between identities, tools, secrets, and persistent memory, so they can amplify a small coding flaw into broad data exposure. They handle file reads, environment variables, and workflow state, which means the framework layer itself becomes part of the access path. That makes identity, secret, and data governance inseparable in agentic systems.
Why This Matters for Security Teams
AI frameworks do more than orchestrate prompts and model calls. They often sit in the middle of identities, tool permissions, secrets, file systems, and persistent memory, which turns the framework layer into an access path rather than a neutral abstraction. That is why a small coding mistake can become a broad nhi governance failure, especially when the framework can read environment variables, retrieve tokens, or reuse workflow state across tasks. NHI risk is already difficult to see: NHIMG research shows only 1.5 out of 10 organisations are highly confident in securing NHIs, based on The State of Non-Human Identity Security. When AI frameworks are added, the visibility problem expands from credentials to behaviour.
Security teams often assume the model is the risk, but in practice the more dangerous layer is the framework that decides what the model can touch and when. That is why guidance from the NIST Cybersecurity Framework 2.0 matters here: identify the asset, define the control boundary, and manage access continuously rather than at deployment time. The practical issue is that agentic systems do not just execute fixed code paths; they chain tools, follow goals, and reuse context in ways that can expose secrets or create unintended privilege. In practice, many security teams encounter framework-driven exposure only after a credential leak, overbroad tool grant, or lateral data read has already occurred, rather than through intentional design.
How It Works in Practice
In agentic systems, governance has to account for autonomous, goal-driven behaviour. A static RBAC model is useful for humans with known job functions, but it breaks down when an AI agent can decide which tool to call, which file to open, or which workflow branch to follow. Current guidance suggests moving toward intent-based authorisation: the decision is made at runtime using the task, context, data sensitivity, and current risk posture. That makes authorisation closer to policy enforcement than to a one-time role assignment.
For that to work, the identity primitive should be the workload, not the prompt. Workload identity, such as SPIFFE-style identities or OIDC-backed tokens, gives the platform cryptographic proof of what the agent is and what instance is acting. Pair that with JIT credentials so the agent receives short-lived access only for the specific action it is performing. Static API keys, long-lived tokens, and broad environment-variable access all increase blast radius. Best practice is evolving toward ephemeral secrets, automatic revocation, and policy-as-code evaluation at request time.
- Issue credentials per task, not per environment, and revoke them on completion.
- Bind tool access to workload identity and runtime context instead of a fixed role alone.
- Log every retrieval of secrets, files, and memory state as a governed access event.
- Use policy engines to check purpose, destination, and data sensitivity before execution.
NHIMG analysis of NHI incidents shows why this matters: the Ultimate Guide to NHIs — Key Challenges and Risks and Top 10 NHI Issues both highlight how over-privilege and weak lifecycle control turn routine automation into recurring exposure. These controls tend to break down when agents are allowed to chain external tools and reuse cached credentials across multi-step workflows because the original approval no longer matches the final action.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance speed against assurance. That tradeoff is real in development sandboxes, high-throughput pipelines, and multi-agent orchestration, where every extra authorisation check can add friction. There is no universal standard for this yet, so teams should treat several practices as emerging guidance rather than settled law.
One common edge case is persistent memory. If a framework stores conversation history, embeddings, or tool outputs, the memory store itself becomes sensitive NHI scope and may need separate controls from the model or agent runtime. Another is delegated access: if an agent acts on behalf of a user, authorisation has to reflect both the user’s intent and the agent’s current privileges, not just a static service account.
NHIMG incident research underscores the operational consequence of getting this wrong. The 52 NHI Breaches Analysis and the OWASP NHI Top 10 show that once a framework can persist state or call tools across sessions, a single compromise can outlive the original task. That is especially true in environments with shared service accounts, weak secret rotation, or loosely separated dev and production paths. For that reason, security teams should treat framework memory, tool connectors, and secret stores as part of the identity plane, not just the application stack.
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 | A2 | Addresses unsafe agent tool use and dynamic permissions in autonomous systems. |
| CSA MAESTRO | G2 | Covers agent governance and identity controls for autonomous AI workflows. |
| NIST AI RMF | GOVERN | AI governance requires accountability for autonomous behaviour and downstream risk. |
Establish workload identity, policy enforcement, and auditability before granting agent execution authority.
