Topic starter
24/06/2026 7:21 pm
TL;DR: AI agent governance breaks at the point of action, 1Kosmos explains, because 60% of organizations cannot terminate a misbehaving agent and 63% struggle to enforce purpose limits. Runtime checks have to sit between the agent and the tool call, or scope can drift beyond what was approved.
Editorial analysis by NHI Mgmt Group, based on content published by 1Kosmos: “Implementing AI Agent Runtime Authorization: A Technical Guide”.
By the numbers:
- 60% of organizations cannot terminate a misbehaving AI agent, according to 1Kosmos.
- 63% are struggling to enforce purpose limitations on what agents are authorized to do, according to 1Kosmos.
Key questions
Q: Why do AI agents need runtime controls instead of only pre-approved access?
A: Pre-approved access cannot tell you what the agent will do once prompts, tools, memory, and sub-agents start interacting.
Q: How do security teams know whether an AI agent control stack is actually working?
A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end.
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context.
Practitioner guidance
- Inventory agent action paths Document which agents exist, which MCP servers they touch, which tools they can invoke, and which credentials or approvals currently let them act.
- Place policy at the MCP boundary Deploy authorization between the agent and the tool call so every request is checked before it reaches the underlying API or service.
- Bind each approval to a narrow action scope Issue credentials that cover a single action class, target resource, and validity window so the agent cannot reuse them outside the approved purpose.
Bottom line: AI agent governance fails when organisations stop at registration, because the real control problem appears when an agent is about to act.
Glossary terms: Runtime Authorisation, Verifiable Digital Credential, CIBA, Ownership Drift
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 hours ago by NHI Mgmt Group
25/06/2026 4:36 am
Runtime authorization is becoming the missing execution-layer control for AI agents: registration tells you an agent exists, but it does not decide whether a specific action should proceed. That distinction matters because most governance models still assume the permission question is settled at provisioning time. In practice, agent risk emerges at the moment of tool use, so the control boundary has to move to execution if teams want enforceable scope.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should be accountable for AI agent approvals and audits?
A: Accountability should sit with the human owner of the agent path, the application owner, and the identity governance process together. The agent cannot be the sole accountable subject because it is not a governance endpoint. Teams should tie approvals, logs, and access reviews to the person or team responsible for the agent’s use.
👉 Read our full editorial: Runtime authorization for AI agents: closing execution-layer control gaps