TL;DR
- Agent actions fall into four tiers by reversibility, data sensitivity, and blast radius.
- Each tier gets a defined approval posture: autonomous, async notification, inline approval, or multi-party approval.
- The framework is enforced at the platform layer, not per agent, so governance compounds across the agent portfolio.
- The most common failure is approval fatigue — gates placed too broadly become rubber stamps.
The question CISOs are actually asking
The "do we allow AI agents" question was settled in most enterprises by mid-2025. The live question in 2026 is "where do we put the approval gates." Leaders who read the research and deploy a dozen agents discover fast that the gate placement decisions are the ones that drive whether the program produces value or produces an incident.
The framework below is what we deploy with clients running our TWSS AI Custom Agents platform and what we review with clients building their own agent programs. It is tier-based because action categories are not uniform; applying the same approval policy to every tool call is either too strict (destroys value) or too lax (creates risk).
The four tiers
Tier 1 — Autonomous
Reversible, low-sensitivity, bounded-blast-radius actions. Read-only queries against internal systems, posting drafts to a personal scratchpad, enqueuing a task for later review. No approval required; the audit log captures the action.
Examples: retrieving a document from the knowledge base, drafting a response the human will later review, classifying a ticket.
Tier 2 — Async notification
Actions with moderate impact but easy reversal. The agent acts; a designated reviewer is notified after the fact with enough context to intervene within an agreed window.
Examples: posting a comment to an internal thread, updating a low-risk field in a CRM record, auto-resolving a ticket in a well-understood category.
Tier 3 — Inline approval
Actions with material impact or external visibility. The agent surfaces the proposed action to a reviewer and waits for explicit approval before proceeding. Inline approval is the pattern most clients default to too widely; good framework design keeps this tier narrow.
Examples: sending an email to an external party, writing a high-value record to a downstream system, approving an expense under a defined threshold.
Tier 4 — Multi-party approval
Actions with severe impact, irreversibility, or regulatory sensitivity. Two or more reviewers must approve. The agent presents full context and waits.
Examples: moving money, writing to a financial system of record, approving an action that affects regulatory filings, deleting production data.
What makes this work at scale
Three design decisions:
Tier classification is configuration, not code. Agent definitions declare which actions fall in which tier. Changing the policy does not require rebuilding agents.
The gate lives at the platform, not the agent. Every agent inherits the same gate infrastructure. One audit log, one notification pipeline, one approval UI.
Tiers are reviewed quarterly. As organizational confidence grows, actions move down a tier. As new risk categories emerge, actions move up.
The approval-fatigue failure mode
The single most common reason this framework fails in production: gates placed too widely. When a reviewer gets twenty approval prompts a day, they approve faster than they read. Within a month, the approval process is a rubber stamp. The security posture is worse than no approval at all, because the audit log shows human approvals that were never real.
The fix is ruthless tier discipline. Tier 3 and Tier 4 should represent a small fraction of total actions. Most actions should be Tier 1 or Tier 2. If they are not, the agent's tool registry is too broad and the scope should be cut before the approval policy is relaxed.
Platform-level controls that enable the framework
- Tool registry with per-tool scope and action classification.
- Approval pipeline routing to the right reviewer via the platform (Slack, web UI, email) with timeout and escalation.
- Full audit log with append-only retention: input, plan, each tool call, approval events, final output.
- Evaluation pipeline that catches tier-violation attempts (agent tried to take a Tier 4 action under a Tier 2 configuration).
- Kill switch. A mechanism to disable an agent or a tool class in real time without waiting for a code deploy.
Where to start
If you are standing up agent governance from scratch, invert the usual approach: classify the tools first, not the agents. Every tool in the registry gets a tier assignment. Agents are then free to use any combination of tools — the gate configuration follows from the tools they call.
For reference architecture, see our TWSS AI Custom Agents case study. For broader context, see our Cybersecurity Solutions and AI & Generative AI services.