They miss the fact that infrastructure controls do not automatically solve identity risk. If the assistant can read HR, trigger APIs, or generate outputs from sensitive systems, it is already behaving like an identity and must be managed that way. The common mistake is to focus on the model while ignoring the permissions attached to the agent.
Why This Matters for Security Teams
Calling an AI assistant “infrastructure” sounds operationally neat, but it hides the real risk: the assistant may already have the power to read sensitive systems, invoke APIs, and produce actions with business impact. That is an identity problem, not just a platform problem. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to map risk, ownership, and safeguards across the full environment rather than assume a tool is harmless because it sits in the stack.
NHIMG research shows how fast this becomes real: in the DeepSeek breach, exposed secrets and backend access were not abstract weaknesses, they were direct pathways to sensitive records and operational compromise. The same pattern appears when teams grant assistants broad access “just to make them useful” and then rely on perimeter controls to contain the blast radius. That approach misses how quickly an assistant can combine permissions, prompts, and tool access into an exploit path.
In practice, many security teams encounter over-privileged AI behaviour only after an assistant has already touched data or triggered an action that was never intended to be machine-driven.
How It Works in Practice
The practical mistake is treating the assistant like a static service account with a neat place in the infrastructure diagram. Autonomous or semi-autonomous assistants do not behave like fixed workloads. They can decide which tools to use, in what sequence, and with what context. That means the meaningful control point is not the model itself, but the identity, authorisation, and runtime policy attached to each task.
Current guidance suggests three layers matter most. First, use workload identity so the assistant can be authenticated as a machine identity rather than by shared secrets alone. In practice, this is where systems like SPIFFE and SPIRE, or short-lived OIDC-based workload tokens, are relevant because they establish cryptographic proof of what the agent is. Second, use just-in-time credentials with short TTLs so access exists only for the task being executed. Third, evaluate policy at request time with context, rather than predefining broad role-based access that assumes stable behaviour. Frameworks such as NIST Cybersecurity Framework 2.0 and emerging identity guidance both point toward this runtime model, while DeepSeek breach is a reminder of what happens when secrets and access are allowed to persist longer than the task requires.
- Issue credentials per workflow, not per environment.
- Limit tool scopes to the smallest action set needed for the current objective.
- Revoke or expire access automatically when the task completes or context changes.
- Log each tool call as an identity event, not just an application event.
This guidance breaks down when teams allow agents to chain tools across multiple systems without a real-time policy engine, because the combined behaviour becomes harder to predict than any single permission grant.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance safety against deployment speed and agent autonomy. That tradeoff is real, especially when teams want assistants to work across tickets, code, cloud, and business systems without constant human approval. Best practice is evolving, but there is no universal standard yet for how much autonomy should be allowed before an assistant is treated as a separate privileged identity.
One common edge case is the “helpful internal assistant” that starts in read-only mode and later gains write access because the business wants automation gains. Another is a multi-agent workflow where one assistant prepares a change and another executes it, which can obscure who actually held the risky permission. A third is environments that rely on long-lived API keys because they are easy to integrate; those keys defeat the point of JIT controls and create standing privilege that outlives the task.
NHIMG’s DeepSeek breach coverage shows why this matters: once secrets, tokens, or backend access are exposed, the assistant is no longer a neutral infrastructure component. It becomes an identity with an attack surface. Teams that keep describing it as “just infrastructure” usually end up underestimating how quickly access sprawl turns into privilege escalation.
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 | A01 | Agentic systems fail when identity and tool access are treated as static infrastructure. |
| CSA MAESTRO | MAESTRO addresses agent autonomy, orchestration risk, and runtime authorization. | |
| NIST AI RMF | GOVERN | AI governance must assign ownership and accountability for assistant-driven actions. |
Treat each assistant as a governed actor with runtime-scoped permissions and explicit action boundaries.
Related resources from NHI Mgmt Group
- What do teams get wrong when they treat AI governance as a compliance project?
- What do teams get wrong when they treat AI security as a detection-only problem?
- What do teams get wrong when they treat AI as the decision-maker?
- What do IAM teams get wrong when they treat agentic AI as just another application?
