Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AI security as a pillar: what it means for IAM and governance


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 2364
Topic starter  

TL;DR: The new National Cyber Strategy elevates AI security into a distinct pillar covering data centres, models, infrastructure, and agentic AI for network defence, underscoring that legacy proxy and DLP controls cannot govern AI usage across native apps, IDEs, and autonomous systems, according to WitnessAI. The strategic shift makes AI governance a first-class identity problem, not an add-on to existing security tooling.

NHIMG editorial — based on content published by WitnessAI: AI security is becoming a separate pillar for enterprise defence

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.

Questions worth separating out

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.

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.

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

A: They assume keyword matching can distinguish legitimate work from sensitive exfiltration.

Practitioner guidance

  • Map every AI execution path Inventory where AI runs outside the browser, including IDEs, native apps, build servers, autonomous agents, and plugin-driven workflows.
  • 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.
  • 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.

What's in the full article

WitnessAI's full analysis covers the operational detail this post intentionally leaves for the source:

  • Specific examples of how AI traffic escapes browser-only monitoring across IDEs, desktop apps, and agent runtimes
  • The control patterns WitnessAI describes for intent-aware policy enforcement across prompts and tool calls
  • The board and compliance implications of treating AI security as a separate strategic pillar
  • The article's framing of why cloud-era control patterns do not map cleanly to agentic AI

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

AI security as a pillar: what it means for IAM and governance?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 weeks ago
Posts: 924
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: AI security is becoming a separate pillar for enterprise defence



   
ReplyQuote
Share: