Because the risk moves from model behaviour to delegated access. Once a GenAI system can retrieve data or trigger actions, any flaw in prompts, integrations, or credentials can become data leakage or unauthorised execution. The practical issue is not AI alone. It is the trust chain around AI.
Why This Matters for Security Teams
Once a GenAI system is connected to business data, the security problem shifts from model quality to delegated access. The system is no longer just generating text; it is querying repositories, summarising sensitive content, and sometimes triggering actions. That creates a trust chain that spans prompts, connectors, secrets, and downstream systems, which is where real exposure begins. NHI Management Group’s Top 10 NHI Issues and the NIST AI 600-1 GenAI Profile both reflect the same operational reality: AI systems become materially riskier when they can reach data or execute actions on a user’s behalf.
That risk is not abstract. In The State of Secrets in AppSec, GitGuardian & CyberArk report that 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases. For security teams, that means the issue is not only leakage through a model response, but also unintended exposure through retrieval, logs, and poorly governed integrations. In practice, many security teams encounter the blast radius only after a connector has already inherited broad permissions and the AI system has already been trusted like a human user.
How It Works in Practice
The practical control problem is the gap between what the model can do and what it should do in a given moment. Static RBAC alone is often too coarse for GenAI workloads because the system’s behavior is dynamic: one request may require a read-only lookup, while the next may involve creating a ticket, querying finance data, or invoking a workflow. Current guidance suggests treating the AI system as an autonomous workload with tightly scoped identity, not as a general-purpose employee account.
That is why teams are moving toward intent-based authorization, just-in-time credentials, and workload identity. Rather than giving a connector a standing token, the platform issues short-lived credentials per task, evaluates policy at request time, and revokes access as soon as the action completes. The identity primitive becomes the workload itself, often backed by cryptographic proof such as SPIFFE/SPIRE identities or OIDC-based federation. This aligns with the trust-chain model described in the OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0, both of which emphasize least privilege, access control, and continuous risk management.
- Use short-lived tokens for each retrieval or action, not reusable long-lived secrets.
- Separate read, write, and tool-invocation permissions so the agent cannot chain access implicitly.
- Evaluate policy at runtime with the current prompt, data classification, user context, and task intent.
- Log each delegated action with enough detail to trace which connector, secret, and dataset were touched.
These controls tend to break down when agents share broad integration tokens across many tools because one compromised path can then expose every connected system.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance user experience against containment. That tradeoff becomes sharper in multi-agent systems, retrieval-heavy workflows, and environments where humans expect the model to “just work” across many internal sources. Best practice is evolving, and there is no universal standard for how granular AI authorisation should be yet.
Some edge cases need special handling. Read-only retrieval can still create leakage if the source data is sensitive, because the model may surface it in an answer or include it in downstream logs. Tool use is riskier still, because an apparently harmless query can become an action chain when the agent can search, extract, and then trigger workflows. The most reliable pattern is to constrain each agent to a narrow business purpose, issue ephemeral access only when needed, and separate high-risk systems such as HR, finance, and production from general-purpose knowledge retrieval. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Key Research and Survey Results are useful reminders that compromised NHI pathways frequently outlast the initial mistake.
Where teams overestimate the model layer and under-govern the connector layer, the weakest link is usually the standing credential, not the prompt.
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 tool use and delegated actions in AI agents. |
| CSA MAESTRO | GOV-2 | Covers governance for autonomous agent behavior and access decisions. |
| NIST AI RMF | Supports managing AI risk across design, deployment, and monitoring. |
Apply AI RMF governance to monitor agent behavior, data exposure, and delegated access.
Related resources from NHI Mgmt Group
- When do AI agent credentials create more risk than they reduce?
- Why do AI agents create more risk when they reuse existing credentials?
- How should security teams limit the risk from AI agents that have access to production systems?
- Why do GenAI chat tools create data leakage risk for IAM and security teams?
