Review identity, authorization, provenance, and recovery first, because those controls determine whether AI can be trusted in production. If the organisation cannot show who the AI is, what it can do, where its data came from, and how it is contained when it fails, the security model is incomplete.
Why This Matters for Security Teams
Adding AI to an existing security model is not just another workload integration. The review has to start with identity, authorisation, provenance, and recovery because those are the controls that determine whether the system can be trusted after first contact with real data and real users. For AI, especially agentic systems, static assumptions age badly. An model that can retrieve data, call tools, and generate outputs can create new paths for privilege escalation, data exposure, and unsafe automation.
Teams often overfocus on model accuracy or prompt quality and underinvest in the control plane around the model. That is where NHIs, secrets, and delegated access become the real risk surface. The State of Non-Human Identity Security shows how common it is for organisations to have limited visibility into non-human access, which is exactly the condition that makes AI adoption hard to govern. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but AI adds a stronger need to prove who or what is acting at runtime, not only at onboarding.
In practice, many security teams encounter AI risk only after an assistant has already connected to production data, rather than through intentional control design.
How It Works in Practice
Start by mapping the AI system as an identity-bearing workload. That means identifying the workload identity, the secrets it uses, the scopes it inherits, the data sources it can reach, and the recovery path if it behaves unexpectedly. For many teams, the cleanest mental model is: the model is not the trust boundary, the surrounding identity and authorisation layer is. This is where workload identity standards such as SPIFFE and short-lived tokens matter, because they prove what the AI workload is at runtime instead of relying on long-lived static credentials.
Next, separate human approval from machine execution. Humans may approve a task, but the AI should receive just-in-time access for that task only, with explicit limits and short TTLs. That reduces the blast radius if the agent chains tools or retrieves data outside its intended purpose. Where possible, use policy-as-code and evaluate permissions at request time, not just at deployment time. For agentic systems, best practice is evolving toward intent-based authorisation, because the request itself may be the only reliable signal of what the AI is trying to do.
The operational checklist usually looks like this:
- Assign a distinct workload identity to each AI service or agent.
- Replace long-lived secrets with ephemeral credentials where feasible.
- Log provenance for training data, retrieval data, and tool outputs.
- Define explicit containment and rollback steps for unsafe or failed actions.
This is also where the DeepSeek breach is a useful reminder that AI systems can create exposure through surrounding controls, not only through the model itself. The State of Secrets in AppSec shows why short-lived, well-governed secrets matter when AI touches code, tokens, or internal APIs. These controls tend to break down when an AI agent is allowed broad tool access across multiple environments because the runtime decision space becomes too large to review manually.
Common Variations and Edge Cases
Tighter AI controls often increase operational overhead, requiring organisations to balance speed of delivery against the cost of continuous verification. That tradeoff is real, especially when teams want to embed AI into existing SaaS, SOC automation, or software delivery pipelines without redesigning every permission path. There is no universal standard for this yet, but current guidance suggests keeping the first rollout narrow and measurable.
One common edge case is a read-only assistant that later gains write access. Teams often underestimate how quickly “read only” becomes “action capable” once the model is connected to ticketing, code deployment, or response tooling. Another is cross-environment sprawl: dev, test, and production often share identities, secrets, or retrieval sources, which makes provenance and containment weak even when the model itself is well tuned. In those cases, the most important question is not whether the AI is accurate, but whether it can be contained, audited, and revoked cleanly.
For governance teams, the practical rule is simple: review identity first, then scopes, then data lineage, then recovery. If those four do not line up, the AI control model is still incomplete.
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 | A1 | Agent identity and tool access are core risks when AI can act autonomously. |
| CSA MAESTRO | I1 | MAESTRO addresses identity, permissions, and runtime governance for agentic systems. |
| NIST AI RMF | AI RMF frames provenance, accountability, and monitoring for trustworthy AI use. |
Map AI agents to explicit workload identities and enforce runtime policy checks for each action.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
