Notifications
Clear all
Topic starter
22/06/2026 10:18 am
TL;DR: AI security is shifting from prompt safety to runtime access control as agents begin executing actions, calling tools, and reaching enterprise data, according to Silverfort. The hard problem is no longer what AI says, but whether identity governance can contain autonomous access before the first API call is made.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams govern AI agents that can take actions on their own?
A: Security teams should govern autonomous agents with runtime access controls, explicit human ownership, and continuous entitlement review.
Q: Why do AI agents create different identity risk than normal automation?
A: AI agents create different risk because they can choose actions at runtime, not merely follow a fixed script.
Q: What breaks when agent access is granted too broadly at build time?
A: When agent access is granted too broadly at build time, developers can unintentionally create standing privilege for autonomous behaviour.
Practitioner guidance
- Map every AI agent to a human owner Require a named accountable owner for each agent, including agents created by citizen developers, and preserve that mapping across delegated roles, service principals, and downstream tool calls.
- Move enforcement into the execution path Apply allow, block, and step-up decisions at the moment an agent requests a tool or data access, so the policy decision is made before the action executes.
- Inventory agent blast radius continuously Track which agents can reach sensitive systems, which permissions are over-broad, and which integrations expand exposure beyond the declared business purpose.
What's in the full announcement
Silverfort's full analysis covers the operational detail this post intentionally leaves for the source:
- How the native Microsoft Copilot Studio integration enforces allow, block, and step-up decisions in practice
- The mechanics of Runtime Access Protection across cloud, hybrid, and on-prem identity paths
- Examples of AI agent discovery and blast-radius scoring across Microsoft, AWS, and GCP environments
- How the MCP Gateway fits into the wider runtime control architecture for agent actions
👉 Read Silverfort's analysis of runtime access control for AI agents in Microsoft Copilot Studio →
AI agent runtime access control: is your governance keeping up?
Explore further
22/06/2026 11:08 am
Runtime access control is now the primary identity problem for AI agents. The article is right to move the discussion away from prompts and outputs. Once an agent can call tools, request data, and make decisions inside a live workflow, the control surface becomes authorisation at execution time. Practitioners should treat the agent session as an identity event with real blast radius, not as a content channel.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for AI agent access decisions?
A: A named human owner should remain accountable for AI agent access decisions, even when the agent operates through delegated credentials or service identities. Accountability needs to survive the delegation chain so policy, incident response, and revocation all point back to a responsible operator.
👉 Read our full editorial: Runtime access control for AI agents is the real security problem
