Notifications
Clear all
Topic starter
24/06/2026 7:23 pm
TL;DR: AI agents are already causing enterprise incidents, and 35% of those cases have direct financial loss, according to Cloud Security Alliance research. The control gap is not agent behaviour alone but the missing runtime identity and action authorization layer that binds each spend to a verified human.
NHIMG editorial — based on content published by 1Kosmos: runtime authorization for AI agents and the identity gap in spending
By the numbers:
- 65% of enterprises running AI agents experienced at least one agent-related incident in the past twelve months.
- 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024.
- 95% had encountered unexpected cloud storage charges that disrupt budgets, slow innovation, or limit flexibility.
Questions worth separating out
Q: How should security teams govern AI agents that can spend money or provision infrastructure?
A: They should treat the agent as a runtime actor, not just a registered identity.
Q: Why do AI agents create more risk than traditional automation for spending controls?
A: Traditional automation follows predetermined rules, while AI agents can decide when to act and what tool path to take at runtime.
Q: What breaks when agent ownership is only recorded at deployment time?
A: The link between the human owner and the actual transaction breaks.
Practitioner guidance
- Separate registration from authorization Keep agent inventory, ownership records, and runtime action approval as distinct controls.
- Interpose a policy engine before every consequential tool call Place an enforcement point in front of procurement, infrastructure, and SaaS management tools so the agent cannot execute a write or purchase action without policy evaluation.
- Bind approvals to verifiable, time-bound credentials Issue credentials only after human approval for the specific action, then scope and expire them so they cannot be reused for a different transaction.
What's in the full article
1Kosmos's full post covers the operational detail this post intentionally leaves for the source:
- The policy interception flow that sits between an MCP call and the target tool.
- The CIBA-based approval path used to bind a human approver to a specific agent action.
- The runtime credential lifecycle, including scope, expiry, and revocation after execution.
- The deployment patterns for infrastructure, procurement, and SaaS-license agents under the same policy engine.
👉 Read 1Kosmos's analysis of runtime authorization for AI agents and spending control →
AI agent spending controls: what changes when runtime identity matters?
Explore further
25/06/2026 4:38 am
Runtime identity is the missing control plane for agentic spending. The vendor correctly frames the problem as execution-time authority rather than registration-time ownership. That matters because agentic systems are not simply automated workflows with a new label. They can choose actions, timing, and tool paths in ways that make static ownership records insufficient for governance. The implication is that action authorization must sit alongside identity issuance, not after it.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorised transaction?
A: Accountability should rest with the governance chain that allowed a standing credential to act without runtime approval. The human approver, the policy owner, and the system owner all have roles, but the key test is whether the specific action was cryptographically bound to a verified approver at the moment of execution.
👉 Read our full editorial: Runtime authorization for AI agents: the identity gap in spending
