Why do AI systems complicate infrastructure and identity governance more than traditional applications?

AI systems introduce dynamic model choices, streaming interactions, agent frameworks, and semantic risks that do not fit neatly into legacy request and response controls. They also depend on external providers, tokens, and tool access, which expands the governance surface. That makes identity, authorization, and observability harder to standardize across teams and workloads.

Why This Matters for Security Teams

AI systems do not behave like conventional applications with a stable caller, a fixed workflow, and predictable outputs. They often introduce model selection, prompt-driven branching, retrieval pipelines, external tools, and short-lived credentials that change the effective trust boundary from one request to the next. That makes governance harder to anchor in static application inventories or simple role assignments.

For security teams, the practical risk is not only misuse, but also ambiguity: who approved the model, who owns the agent’s action scope, which secrets it can reach, and how output is validated before it drives a downstream action. Those questions sit across architecture, identity, data protection, and operations, so gaps often persist when each team assumes another control layer is handling them. The NIST Cybersecurity Framework 2.0 is useful here because it forces organisations to map governance, protection, detection, and recovery responsibilities across the full system lifecycle.

In practice, many security teams encounter the real failure only after an AI workflow has already overreached its intended access or acted on unvalidated output, rather than through intentional governance design.

How It Works in Practice

AI governance becomes more complex because the control problem shifts from one application to a chain of interacting components. A traditional service usually has a bounded identity, a known API surface, and well-defined inputs and outputs. An AI system may include a foundation model, a retrieval layer, orchestration logic, plugins, human review points, and one or more external providers. Each of those layers can introduce different policy requirements, audit needs, and failure modes.

From an identity perspective, the hard part is separating human intent from machine execution. Agents may act with delegated authority, but the delegation is often indirect: a user triggers a workflow, the agent calls a model, the model requests a tool, and the tool uses a secret or token that grants broader access than the user originally intended. That is why identity governance for AI systems should track not only human users, but also service identities, model-to-tool trust, and secret lifecycles. Current guidance suggests treating these as distinct control planes rather than assuming existing IAM policies will cover them automatically.

Operationally, teams should focus on a few controls:

• Define the approved model and provider list, including where data may be sent.
• Separate human approval from machine execution for high-impact actions.
• Constrain tool use with least privilege, short-lived tokens, and explicit scopes.
• Log prompts, tool calls, retrieval sources, and outputs for review and incident response.
• Validate outputs before they trigger financial, security, or customer-facing actions.

Where AI systems use external data or model updates, integrity also becomes part of governance. The model may be sound at deployment but still degrade through prompt injection, poisoned retrieval content, or weak approval logic around new connectors. The OWASP Top 10 for Large Language Model Applications and MITRE ATLAS are helpful references for mapping these attack patterns to practical defenses. These controls tend to break down when organisations allow ad hoc agent tooling across distributed teams because ownership, logging, and revocation become inconsistent.

Common Variations and Edge Cases

Tighter AI governance often increases operational overhead, requiring organisations to balance stronger oversight against delivery speed and experimentation. That tradeoff matters because not every AI workload carries the same risk. A read-only summarisation assistant does not need the same approval chain as an agent that can create tickets, move funds, or modify cloud resources.

Best practice is evolving for several edge cases. For example, some teams treat retrieval-augmented generation as a data problem, while others treat it as a model-risk problem because the retrieved content directly shapes the answer. Both views are partly correct, and there is no universal standard for this yet. The same ambiguity applies to identity: a model that only drafts content may need minimal execution authority, but an agent that uses service accounts to take action needs explicit accountability, revocation, and monitoring.

There is also an important boundary issue with vendor-hosted systems. If a provider manages the model but the organisation controls the prompts, data, and downstream automation, governance must still cover provenance, retention, and approval flows. For regulated or safety-sensitive use cases, current practice increasingly aligns with NIST AI Risk Management Framework and emerging AI-specific guidance, but implementation maturity varies widely across sectors. The biggest exception is legacy infrastructure with rigid PAM and change-control processes, where AI workflows can be forced into manual approval paths that slow adoption without fully reducing risk.

Related resources from NHI Mgmt Group

• Why do agentic AI systems complicate identity governance more than traditional service accounts?
• Why do agentic systems complicate identity governance more than traditional SaaS integrations?
• Why do AI SOC agents complicate identity governance more than traditional SOAR?
• Why do AI systems complicate GDPR compliance more than traditional software applications?