The Approval Debt Hiding Inside Your AI Agent Rollout

The latest joint guidance on agentic AI from the Australian Cyber Security Centre, CISA, NSA and partner agencies makes one recommendation that should stop every enterprise AI program in its tracks: do not give agents broad or unrestricted access, especially to sensitive data and critical systems.

That sounds obvious. It is also where most agent rollouts quietly fail.

The failure is not usually a dramatic decision to give an AI agent domain admin. It is a pile of reasonable shortcuts: a shared service account to get a pilot working; an OAuth grant that is broader than the agent needs; a sandbox connector that remains live in production; a manager who owns the business outcome but not the credential; an approval step removed because it slowed the demo down.

Those shortcuts create approval debt. It compounds while the team is busy celebrating adoption, turning a business workflow into a security decision without anyone explicitly making it.

Agents turn permissions into behaviour

A chatbot can expose information. An agent can expose information, decide what to do next, call a tool, retry when it fails and hand work to another system. The security question is no longer just, "Can this identity read this data?"

It is, "Can this agent use that data, through this tool, to take this action, in this environment, for this approved purpose?"

That is a much more demanding question. Traditional IAM was designed around people with reasonably stable job roles, and service accounts built for defined workloads. Agents are goal-driven. Their permissions may be technically valid while their next action is outside what the business intended.

The joint guidance calls out the expanded attack surface created by agents' tools, external data sources, memory and integrations. It also highlights indirect prompt injection: malicious content embedded in an email, document or web page can influence an agent that is allowed to read and act on that content. This is not an obscure model problem. It is the practical consequence of connecting an autonomous system to real enterprise systems.

A useful rule follows: every permission an agent receives must be evaluated as a possible action, not just a possible read.

Discovery is necessary. It is not governance.

Many organisations have begun by cataloguing sanctioned AI tools and asking employees to register agents. You cannot govern what you cannot find.

But an inventory that ends at the agent name, vendor and owner is mostly a comfort blanket. It does not tell a security team whether the agent uses a standing credential, whether it can move data between systems, whether it has been active recently, or whether it can take an irreversible action without a human checkpoint.

A governable agent record needs five fields at minimum:

• **Business owner:** The accountable person who can explain why the agent exists and accept its risk.
• **Approved purpose:** A specific, bounded outcome. "Help operations" is not a purpose. "Draft a weekly inventory variance report from these approved sources" is.
• **Identity and access path:** Every OAuth grant, API key, service account, connector and delegated user context.
• **Action boundary:** What the agent may read, create, change, send, approve or delete, including the systems and environments involved.
• **Lifecycle state:** Pilot, approved, production, paused, retired. Dormant agents and abandoned credentials need a state too.

If one of those fields is unknown, the agent is not ready for high-impact work. It should not be treated as a trusted production actor.

Replace blanket approvals with action tiers

The fastest way to make agent governance operational is to stop approving "the agent" as a single object. Approve categories of action instead.

For example, a support agent may be allowed to read a customer's existing ticket history and draft a response. It may be allowed to create a draft ticket. It should not be allowed to export customer records, change account entitlements or send a bulk message simply because it has access to the support platform.

A practical tiering model looks like this:

1. Observe: Search, summarise, classify and draft. Log activity, but do not require a person for each low-risk action. 2. Recommend: Propose changes to a human owner. The agent can assemble evidence and prepare the change, but cannot execute it. 3. Execute with guardrails: Make reversible, bounded changes in approved systems. Enforce transaction limits, environment restrictions and full audit logs. 4. High-impact actions: Payments, privilege changes, production deployments, bulk exports, external communications and deletion. Require explicit human approval and a narrowly scoped, short-lived credential.

This approach lets teams move quickly without pretending every agent action is equally risky. It gives security and compliance teams a testable policy.

The most important control is short-lived authority

An agent that needs a permanent, broad credential is usually an agent whose design has not caught up with its ambition.

Use just-in-time access wherever possible. Bind authority to the task, environment, data classification and time window. Give the agent a dedicated identity rather than a shared human account. Make the credential expire when the approved job ends. Put production actions behind an approval workflow, not a prompt.

This matters because model behaviour is not a security boundary. A system prompt can guide an agent, but it cannot revoke an API token or stop a connector from accepting a valid request. Enforcement needs to sit at the identity, tool and data layers where actions actually happen.

It also means logging must be designed for investigation, not theatre. Record the agent identity, initiating user or workflow, tools called, data sources accessed, policy decision, action result and approver for high-impact actions. A chat transcript alone will not explain a security event.

Build the control plane before the agent estate becomes invisible

The agencies behind the new guidance recommend aligning agentic AI risks with existing security models rather than treating AI as a separate discipline. That is the right instinct. Agent governance belongs in IAM, data security, application security, cloud security and change management.

The catch is that enterprise agents now appear across SaaS platforms, internal apps, coding tools, workflow automation and employee-built prototypes. Platform-by-platform settings will not create enterprise control. They create fragmented visibility and inconsistent enforcement.

This is where shadow AI becomes dangerous. Useful agents are easy to create and hard to see once they inherit a real connector. A marketing workflow that can access a customer list, an analyst's browser-based agent with a cloud token, or a developer's local automation can all become production-adjacent before security ever sees a change request.

Aona helps organisations discover AI use across the environment, understand which tools and agents are touching sensitive data, and apply governance that does not depend on slowing every team down. The goal is not to ban agents. It is to make their authority explicit, bounded and auditable before approval debt becomes an incident.

The question for security leaders this week is simple: which of your agents can act today, and who explicitly approved each action they can take? If the answer is a spreadsheet, a vendor console or "we think the owner is still on that team," you have approval debt. Start paying it down now.