AI security is becoming a separate pillar for enterprise defence

At a glance

What this is: This is an analysis of how the new National Cyber Strategy elevates AI security into a distinct defensive discipline and why legacy controls fail to govern agentic AI and AI-heavy workflows.

Why it matters: It matters because IAM, PAM, and governance teams now have to treat AI systems as privileged actors with access, auditability, and policy boundaries, not just as another application channel.

By the numbers:

• That browser-only visibility misses the 80% of AI usage happening in native applications, IDEs, and agent frameworks.
• Within 18 months, every major federal contractor and regulated enterprise was scrambling to align.

👉 Read WitnessAI's analysis of why AI security now needs its own pillar

Context

AI security is becoming a distinct governance problem because AI systems can interpret intent, generate content, take actions, and increasingly operate autonomously. That changes the identity question from who signed in to what the system is allowed to do, where it can act, and how far its privileges extend across data, tools, and transactions.

The strategy described in the source treats AI as infrastructure to defend, not just technology to monitor. For IAM and security teams, that means the control plane has to expand beyond browser-centric monitoring and static policy matching to cover agentic execution, external plugins, and machine-speed decision paths.

Key questions

Q: How should security teams govern AI systems that can take actions, not just generate output?

A: Treat them as governed identities with explicit ownership, bounded scope, audit trails, and interruptible execution paths. If an AI system can call tools, access data, or trigger transactions, the control model must cover authorization and accountability at runtime, not only sign-in events. That is the difference between monitoring an application and governing an actor.

Q: Why do browser-based controls fail for AI security?

A: Because much AI activity now happens outside the browser in IDEs, native apps, build servers, and agent frameworks. Browser controls can see a session, but they cannot see the full execution path or the downstream actions triggered by the system. Effective governance has to follow where the AI actually runs.

Q: What do organisations get wrong about DLP for AI use cases?

A: They assume keyword matching can distinguish legitimate work from sensitive exfiltration. In practice, AI prompts are contextual, so the same text may be safe in one workflow and dangerous in another. Teams need policy that evaluates intent, destination, and action, not just strings.

Q: Who should own AI governance when agents connect to production systems?

A: Ownership should sit with the team responsible for the data, tools, and transactions the agent can touch, with IAM and security architecture enforcing the boundaries. If nobody can explain who approved the access, who can revoke it, and who reviews the actions, the agent is over-scoped by default.

Technical breakdown

Why proxy-based visibility misses AI agent activity

Legacy web proxies can log destinations, but they do not understand prompts, tool calls, or the context of an AI workflow. AI activity now appears in native apps, IDEs, embedded copilots, build servers, and autonomous agents, which means the actual attack surface is distributed across endpoints and runtime environments. A browser-only model sees only a slice of the interaction. That creates a blind spot for exfiltration, unsafe tool use, and policy bypass through non-browser paths.

Practical implication: extend monitoring beyond browser traffic and map where AI actually executes, not where you assume it runs.

Why keyword DLP fails for intent-aware AI governance

Traditional DLP works best when sensitive data has predictable formats such as file names, card numbers, or regex-matched patterns. AI interactions are different because the same prompt can support legitimate work or reveal proprietary information depending on context and intent. That makes content inspection alone insufficient. Governance has to account for purpose, workflow stage, and session context, not just the presence of secret-looking text.

Practical implication: add intent and workflow context to DLP decisions instead of relying on keyword matches alone.

How agentic AI changes the identity model

An AI agent that can access production systems, call APIs, and execute transactions acts like a digital worker with inherited permissions. The security issue is not only authentication, but authorization at machine speed without human judgment at the point of execution. Once plugin architectures and autonomous actions are involved, the relevant identity question becomes whether the agent can act within a bounded, auditable scope. That is an identity and governance problem, not just an application control problem.

Practical implication: treat agent permissions as governed identity entitlements with audit and stop conditions, not as casual app integrations.

Threat narrative

Attacker objective: The objective is to turn legitimate AI access into high-speed unauthorized action that reaches sensitive data, systems, or transactions before defenders can intervene.

1. Entry occurs when an AI agent or connected workflow is given access to sensitive systems such as CRM, code repositories, financial tools, or external plugins.
2. Credential or permission abuse follows when the agent inherits broad access and uses APIs or transactions at machine speed outside human review.
3. Impact appears as source code exfiltration, unauthorized financial transfer, poisoned deployment, system outage, or a compliance violation triggered by the agent’s action path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security is now a governance pillar because the old control stack cannot express machine-speed decision rights. Proxies, DLP, and browser controls were built for content and network inspection, not for actors that interpret intent and execute actions across tools. Once AI systems can move from conversation to transaction, the identity problem shifts from access visibility to runtime authority. Practitioners should stop treating AI as a monitored application and start treating it as a governed identity surface.

The bolt-on security model fails because AI activity is not confined to one channel or one control plane. The source correctly shows that browser-centric visibility misses most real usage and that static policies cannot govern autonomous systems. That is not a tooling gap alone. It is a category error in how AI risk is framed. Practitioners should assume that any control built only for web sessions will leave native apps, IDEs, and agents outside governance.

AI agent privilege is a named identity problem, not a generic application risk. The most useful concept here is agent authority sprawl: permissions inherited from humans but exercised by systems that act faster, wider, and with less oversight than the approving user intended. That sprawl spans data access, tool invocation, and transaction execution. Practitioners should govern the agent as a distinct identity class with explicit scope and accountability.

Agentic AI collapses the distinction between access and action. Enterprises often assume that if a system has permission, a human will still be the one deciding when to use it. That assumption fails when the actor can select tools, time actions, and trigger external side effects on its own. The implication is not just better policy, but a rethinking of where decision authority actually sits in the control chain.

The regulatory signal is likely to pull AI security into board and audit workflows faster than many teams expect. Once policy frameworks and procurement requirements align to a national strategy, security evidence becomes part of governance proof, not just engineering hygiene. That means IAM, GRC, and security architecture have to converge around AI entitlements, logging, and stop mechanisms. Practitioners should prepare for AI controls to be asked about in the same way cloud and zero trust controls are now.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security. That gap shows the market is moving faster than governance.
• For the lifecycle angle, see Top 10 NHI Issues for the access and accountability patterns that AI programmes inherit when they scale.

What this signals

Agent authority sprawl: the next governance failure will come from systems that inherit broad access from humans but act at machine speed with no equivalent review cadence. With 70% of organisations already granting AI systems more access than human employees, the control issue is no longer whether AI is used, but whether the enterprise can explain its effective privilege model.

The strategy will push more teams toward AI-specific audit evidence, especially where autonomous actions, plugins, and external APIs are involved. That means IAM programmes should expect pressure to prove ownership, scoping, and revocation for AI identities in the same way they now evidence cloud or privileged access governance.

If your current model cannot separate prompt handling from tool execution, the gap will widen as agentic workflows spread into engineering and operations. Aligning with the NIST AI Risk Management Framework gives teams a language for governance, but the real work is proving who can act, when, and under what stop condition.

For practitioners

• Map every AI execution path Inventory where AI runs outside the browser, including IDEs, native apps, build servers, autonomous agents, and plugin-driven workflows. Prioritise the paths that can reach sensitive systems or issue downstream actions, because those are the ones legacy monitoring is least likely to see.
• Classify AI systems as governed identities Assign explicit owners, scopes, and approval boundaries to each agent, assistant, or model workflow that can access data or tools. Do not leave permissions implicit in the host application or inherited from the first human user who created the workflow.
• Add intent-aware policy to DLP and proxy controls Combine content inspection with workflow context, destination sensitivity, and action type so the control can distinguish legitimate AI use from data movement or unsafe tool invocation. Static keyword matching is not enough for conversational or agentic interactions.
• Define stop conditions before autonomous actions reach production Require audit trails, approval gates, and revocation paths for agents that can call APIs, move money, or alter infrastructure. The control must interrupt execution before the agent completes the transaction, not after the fact.
• Brief the board on AI as a control-plane issue Frame AI security as a governance and identity problem with compliance, operational, and resilience implications. Boards will expect evidence that AI access is being managed with the same discipline as other privileged systems.

Key takeaways

• AI security has moved from an adjacent control problem to a distinct governance discipline because AI systems can now act, not only respond.
• Legacy browser, proxy, and keyword-based controls cannot fully govern native, embedded, and agentic AI workflows.
• Practitioners should treat AI systems as privileged identities with explicit scope, accountability, and interruption points before autonomy expands further.

Key terms

• Agent Authority Sprawl: Agent authority sprawl is the spread of permissions across AI systems that inherit access from humans but exercise it at machine speed. It creates a governance gap when scope, timing, and downstream actions are no longer visible in the same way as human use of the account.
• Intent-Aware Policy: Intent-aware policy evaluates what a user or system is trying to do, not just what text or network event it produces. For AI security, it must consider context, workflow, and execution path so legitimate assistance is not confused with data loss or unsafe action.
• Agentic AI: Agentic AI is AI that can select actions, call tools, and execute tasks with limited or no human intervention. In governance terms, it behaves like a non-human identity with decision rights, which means identity, authorization, and audit controls must be designed for runtime action, not only access.
• Control Plane: A control plane is the set of policies, identity checks, and enforcement points that decide what a system may do. For AI programmes, the control plane must reach beyond browser monitoring and cover agents, plugins, APIs, and the systems that consume their output.

Deepen your knowledge

AI security as an identity and governance discipline is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents, copilots, and AI-enabled workflows, it is worth exploring.

This post draws on content published by WitnessAI: AI security is becoming a separate pillar for enterprise defence. Read the original.