Notifications
Clear all
Topic starter
26/08/2026 11:51 am
TL;DR: Agent identity protocols cover naming, registration, and credential binding, but leave the most important question unanswered: who decides whether each tool call should proceed, according to Cakewalk. The missing layer is runtime governance, where every action is evaluated against the human behind the agent, the target system, and the requested operation.
NHIMG editorial — based on content published by Cakewalk: Runtime Governance: The Missing Layer for Agent Access
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Q: Why are agent identity protocols not enough on their own?
A: They solve discovery, registration, and credential binding, but they do not answer the runtime question of whether a particular action should proceed.
Q: What breaks when AI agents inherit a human's permissions without runtime checks?
A: Accountability breaks first, because the enterprise loses the point where intent, scope, and permission are evaluated together.
Practitioner guidance
- Map every agent tool call to a policy decision Place an authorization check in the execution path so each tool invocation is evaluated against the action, the delegating human, and the target system before it reaches the app.
- Separate agent registration from action approval Use identity protocols for discovery and lifecycle, but do not mistake registration, naming, or credential binding for permission to act.
- Define deny rules for destructive operations Block actions such as deletion, bulk export, or privilege change unless the runtime policy explicitly allows them for that specific delegated context.
What's in the full article
Cakewalk's full article covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of the five agent identity protocols and where each one stops governing behaviour.
- Architecture diagrams showing protocol gateway, SDK, kernel, and vendor-app enforcement patterns.
- The full runtime governance flow for approve, deny, and escalate decisions across tool calls.
- The complete Decision Trace model that records delegation, policy inputs, and execution outcomes.
👉 Read Cakewalk's analysis of runtime governance for agent access →
Agent access without runtime governance: what changes now?
Explore further
26/08/2026 11:51 am
Runtime governance is the missing security layer for delegated agent access. Agent identity protocols solve naming, discovery, and credential binding, but they do not decide whether a specific action should happen. That leaves enterprises with authenticated agents that can still behave outside acceptable bounds. The practitioner conclusion is simple: identity for agents is necessary, but it is not sufficient without per-action control.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when a delegated agent performs the wrong tool action?
A: Accountability should rest on the decision chain, not only on the session owner. You need to know who approved the delegated action, which policy version applied, what token was bound to the child principal and what side effect occurred. Without those records, accountability becomes speculative instead of provable.
👉 Read our full editorial: Runtime governance is the missing layer for agent access
