NIST AI Risk Management Framework, OWASP Agentic AI Top 10, and MITRE ATLAS are the most relevant starting points when AI systems can reason, call tools, and touch data. Identity teams should pair them with NHI governance so credentials, permissions, and runtime reach are reviewed together instead of in separate silos.
Why This Matters for Security Teams
AI systems that use internal tools are no longer passive chat interfaces. They can retrieve records, open tickets, trigger workflows, query APIs, and write back to business systems. That changes the risk model from output quality alone to execution authority, data exposure, and change control. The most useful frameworks therefore focus on model behaviour, tool access, and governance, not just prompt safety.
For security teams, the practical issue is that an AI system may be “well guarded” at the model layer while still being over-permissioned in the runtime layer. A tool-enabled agent can cause real impact if its credentials, scopes, or approval paths are too broad. NIST Cybersecurity Framework 2.0 is useful here because it keeps governance tied to operational outcomes such as asset management, access control, monitoring, and response, which is a better fit than treating AI as a standalone experiment.
Current guidance suggests treating internal tools as part of the AI attack surface. That includes prompt injection through retrieved content, insecure function calling, unintended data access, and weak logging around agent actions. In practice, many security teams encounter these failures only after an agent has already touched production data or executed an approved-looking workflow rather than through intentional governance review.
How It Works in Practice
The strongest approach is to govern the AI system as a chain of risk points: the model, the orchestration layer, the tools, and the identity controls that allow execution. NIST AI Risk Management Framework helps organisations define ownership, measure risk, and set lifecycle governance. OWASP agentic ai Top 10 is more tactical, highlighting abuse patterns such as indirect prompt injection, excessive agency, insecure tool use, and sensitive data leakage. MITRE ATLAS adds a threat-oriented view for adversarial techniques against AI systems and their surrounding pipelines.
In practice, teams should ask four questions before an AI system gets tool access:
- What tools can it call, and are those tools limited to the minimum needed?
- What identity does it use at runtime, and is that identity unique to the workload?
- What approval, logging, and replay controls exist for high-impact actions?
- What data can the agent retrieve, transform, or write back?
Identity governance matters because the tool layer often inherits the weakest part of the stack. If an agent uses shared service credentials, inherited roles, or broad API tokens, the AI control problem becomes a privileged access problem. That is where NHI governance should be paired with AI governance so secrets, token rotation, scope review, and revocation are tracked alongside model and prompt controls. The NIST guidance on cyber risk governance is also useful for aligning this work to broader enterprise controls, and the NIST Cybersecurity Framework 2.0 provides a common structure for that mapping.
Teams should also validate outputs before actions are executed. For example, an agent that drafts a change request should not be the same component that applies the change unless the action is narrowly bounded and fully monitored. These controls tend to break down when legacy automation, shared API keys, and human approval workflows are mixed into the same service account because attribution and revocation become unclear.
Common Variations and Edge Cases
Tighter tool restrictions often increase operational overhead, requiring organisations to balance agent autonomy against auditability and blast-radius reduction. There is no universal standard for how much autonomy is acceptable yet, so the right answer depends on business criticality, data sensitivity, and whether the action is reversible.
Some environments need stronger guardrails than others. Customer support agents that only draft responses can usually operate with lower-risk controls than agents that can modify records, initiate payments, or access regulated data. In those higher-impact cases, best practice is evolving toward step-up approval, just-in-time permissions, and separate identities for retrieval, reasoning, and execution.
Another edge case is the difference between sandboxed experimentation and production deployment. A prototype may look safe because it uses synthetic data and limited tools, but the control model can fail once it is connected to real systems with long-lived credentials. That is why governance should be reviewed again at cutover, not only during development. The OWASP Top 10 for Large Language Model Applications is useful for identifying these failure modes, while MITRE ATLAS helps teams think in attacker terms rather than feature terms.
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, MITRE ATLAS and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Covers governance, measurement, and lifecycle risk for AI systems with tool use. | |
| OWASP Agentic AI Top 10 | Highlights prompt injection, excessive agency, and insecure tool-use risks. | |
| MITRE ATLAS | Maps adversarial techniques against AI systems and surrounding pipelines. | |
| NIST CSF 2.0 | PR.AC-4 | Tool access depends on least-privilege identity and access governance. |
| OWASP Non-Human Identity Top 10 | AI toolchains often rely on service identities, tokens, and secrets. |
Assign owners, assess risk across the AI lifecycle, and document controls before production release.
Related resources from NHI Mgmt Group
- How should security teams govern AI systems that use retrieval and internal knowledge bases?
- How should security teams govern generative AI tools that connect to core systems?
- How should security teams govern AI agents that use service accounts and MCP tools?
- How should security teams govern employee use of public AI tools in the browser?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
