Notifications
Clear all
Topic starter
02/08/2026 11:23 am
TL;DR: Agentic AI breaks core security assumptions about known assets, deterministic behavior, and identity-based authorisation, and practitioners are converging on scoped identity, action-level approval, observability, and containment, according to OXSecurity. Static IAM models fail when agents make runtime decisions across tool chains and shadow AI expands faster than governance can track; the control problem is dynamic, not merely access-based.
NHIMG editorial — based on content published by OXSecurity: agentic AI governance and the new rules of runtime containment
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do traditional IAM controls struggle with autonomous AI agents?
A: Traditional IAM assumes predictable users or static machine accounts, but AI agents can act independently, interact with multiple systems, and generate new access needs over time.
Q: What do security teams get wrong about Shadow AI?
A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem.
Practitioner guidance
- Define scoped identities for every agent Assign each agent a distinct identity with no shared credentials and no standing access.
- Require action-level approval for high-impact operations Put explicit approval gates on actions that can change infrastructure, move data, or touch production systems.
- Instrument full agent observability Log prompts, tool calls, command context, and MCP interactions with enough detail to reconstruct intent after the event.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Panel context from VibeSecCon Returns 2026, including the practitioner discussion that shaped the framework
- Detailed examples of how observability is captured across prompts, tool calls, and MCP interactions
- Operational discussion of build-fail policy, runtime feedback loops, and control-plane enforcement
- The source article's framing of how teams should respond when an agent behaves unexpectedly in production
👉 Read OXSecurity's analysis of agentic AI governance and runtime containment →
Agentic AI authorization and containment: are your controls keeping up?
Explore further
02/08/2026 12:40 pm
Static IAM assumptions do not survive agentic execution. Identity-based authorisation was designed for actors whose intent can be inferred from a request and whose actions are bounded by predefined workflows. That assumption fails when the actor can select tools, chain decisions, and change direction mid-session. The implication is not simply stronger policy, but a recognition that the old authorisation model no longer describes the behaviour being governed.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity inventory remains even before agentic complexity is added.
A question worth separating out:
Q: Who is accountable when a multi-agent system causes damage?
A: Accountability cannot stop at the original deployer if the system hands off decisions across several agents and tools. The governance model has to reflect the whole delegation chain and the specific action that caused the impact, not just the first human involvement.
👉 Read our full editorial: Agentic AI governance needs dynamic controls, not static IAM
