AI Agent Risk Tiering Framework: How to Decide What Agents Can Do Autonomously

Why Most Agent Governance Fails Before It Ships

Every enterprise AI team hits the same wall. Someone asks: "What can this agent do on its own?" And the answer is either "everything" or "nothing." Both are wrong.

We run 385+ agents in production across SAP, NetSuite, Oracle, Salesforce, and ServiceNow. Early on, we tried the binary approach: agents either needed approval for every action or ran fully autonomous. The first option created approval queues so deep that the agents were slower than the humans they replaced. The second generated incidents that eroded trust with the exact stakeholders we needed as champions.

The breakthrough was simple in hindsight: risk is not a property of the agent. It is a property of each individual action the agent takes. An agent reading a ServiceNow ticket and the same agent posting a journal entry in SAP are fundamentally different risk events. They need different controls, different audit trails, and different escalation paths.

That insight drove us to build a scoring-based risk tiering system. Here is exactly how it works.

How We Score Risk in Production

After testing dozens of scoring models, we settled on four dimensions that capture what compliance, finance, and operations teams actually need to evaluate. Not five, not ten. Four scored dimensions that our customers can tune per tenant without calling us.

Financial Exposure (1-5). What is the maximum monetary impact if this action executes incorrectly? Reading inventory levels in SAP scores a 1. Submitting a payment batch scores a 5. This dimension is the one every stakeholder intuitively understands, so it anchors the conversation.

System Impact (1-5). How broadly does this action affect connected systems and data? An action scoped to a single record in one system scores low. An action that triggers downstream workflows across SAP's 34,000+ managed objects or cascades into Salesforce deal records scores high. System impact captures blast radius, which financial exposure alone misses.

Reversibility (1-5). Can this action be undone, and at what cost? Creating a draft purchase requisition is fully reversible, a 1. Sending an external customer email is irreversible, a 5. Posting a journal entry is technically reversible with a correcting entry, but the audit implications push it to a 4. Reversibility is the dimension that separates recoverable mistakes from incident responses.

Regulatory Scope (1-5). Does this action touch data or processes governed by specific regulations? Internal-only actions with no PII score a 1. Actions involving SOX-controlled financial records, GDPR-covered personal data, or regulated health information score 4 or 5. This dimension exists because regulatory violations have consequences that scale independently of the action's other properties.

Each action gets a composite score from 4 (minimum) to 20 (maximum). No weighting. We tried weighted models early on and found they created false precision that made the tiers harder to explain to governance committees. The raw sum works better because every stakeholder can look at the four numbers and understand exactly why an action landed in a given tier.

The Three Tiers and What They Actually Do

The composite score maps to three tiers. Each tier prescribes a specific control pattern, logging behavior, and SLA.

Tier	Score Range	Execution Model	Logging	SLA
Tier 1 (Low)	4-8	Auto-execute, no approval needed	Async logging	None
Tier 2 (Medium)	9-14	Auto-execute with mandatory post-review	Sync logging, review within 4 hours	4h review window
Tier 3 (High)	15-20	Blocked until pre-approval	Full audit trail, complete decision trace	2h approval SLA, 4h escalation

These are not suggestions. Every action that scores 15 or above is physically blocked from executing until a named approver signs off. Every action in Tier 2 executes immediately but enters a review queue with a 4-hour window. If the reviewer identifies an issue, rollback triggers automatically where the target system supports it.

The SLA structure on Tier 3 matters more than people expect. A 2-hour approval SLA with a 4-hour escalation means high-risk actions do not sit in someone's inbox for days. If the designated approver does not act within 2 hours, the request escalates. This prevents governance from becoming a bottleneck while maintaining the control.

Concrete Scoring: 3-Way Invoice Matching

Abstract frameworks are useless without concrete examples. Here is how risk tiering works on one of the most common enterprise processes: 3-way invoice matching across purchase order, goods receipt, and vendor invoice.

Step 1: Read PO details from SAP. Financial Exposure: 1 (read-only). System Impact: 1 (single system query). Reversibility: 1 (no state change). Regulatory Scope: 1 (no regulated data). Total: 4. Tier 1. Auto-executes instantly.

Step 2: Match invoice line items to PO and receipt. Financial Exposure: 2 (matching errors could delay payment). System Impact: 2 (touches PO and receipt records). Reversibility: 2 (match results can be recalculated). Regulatory Scope: 2 (financial records, but no posting yet). Total: 8. Tier 1. Still auto-executes, but the score is right at the boundary.

Step 3: Flag discrepancies and route for resolution. Financial Exposure: 3 (routing errors delay payment, affect vendor relationships). System Impact: 3 (creates tasks, sends notifications). Reversibility: 2 (routing can be reassigned). Regulatory Scope: 2 (pre-posting workflow). Total: 10. Tier 2. Executes immediately, but the routing decision enters a review queue.

Step 4: Post matched invoice for payment. Financial Exposure: 5 (direct financial commitment). System Impact: 4 (triggers AP posting, GL entries, potential payment run). Reversibility: 4 (requires correcting entries with audit trail). Regulatory Scope: 5 (SOX-controlled financial posting). Total: 18. Tier 3. Blocked until an AP manager approves.

One process, four steps, three different risk tiers. That is the granularity you need.

The Rules Engine Behind the Tiers

Scoring alone does not handle the real complexity of enterprise approval logic. An invoice for $500 has different governance requirements than one for $500,000, even if both score identically on the four dimensions. A procurement action in a regulated cost center needs different controls than the same action in a general overhead center.

We use a neuro-symbolic rules engine that combines neural confidence scores with deterministic business rules. The neural side evaluates the agent's confidence in its decision: did the invoice matching agent identify the line items correctly? Is the extraction confidence above threshold? The deterministic side applies hard business rules that never bend regardless of confidence.

The rule types break down into four categories:

• Compliance rules enforce regulatory requirements. SOX controls on financial postings, data residency restrictions, segregation of duties.
• Validation rules check data integrity. Does the PO exist? Does the amount match within tolerance? Are required fields populated?
• Routing rules determine who reviews or approves. Based on amount thresholds, cost center ownership, document type, organizational hierarchy.
• Threshold rules set dynamic approval levels. Different dollar amounts trigger different approval chains. Different document types require different reviewers.

These rules evaluate using operators like equals, greater_than, less_than, contains, and specialized operators like count_less_than and has_duplicates for batch validations. The key detail: every rule evaluation is logged with the neural confidence score that accompanied it. When an agent decides an invoice matches a PO at 94% confidence and the threshold rule requires 90%, the audit trail shows both numbers and the rule that was applied.

Customers define their own rules per tenant. A pharmaceutical company's compliance rules look nothing like a manufacturing firm's. The framework is the same; the rule definitions are entirely customer-specific.

How Approval Thresholds Actually Work

Static tier assignments are not enough. The same action type can require different approval paths depending on context. Our approval thresholds evaluate across five contextual dimensions:

Document type. A standard purchase order versus a blanket purchase agreement versus a contract amendment, each carries different inherent risk even at the same dollar amount.

Amount. Obvious but nuanced. The thresholds are not just "above $10K needs VP approval." They layer: under $1K auto-executes, $1K-$10K needs manager review, $10K-$50K needs director approval, above $50K needs VP sign-off.

Cost center. Actions against R&D cost centers might auto-execute at higher thresholds than actions against regulated manufacturing cost centers.

User role. An agent acting on behalf of a procurement specialist has different authority than one acting on behalf of an accounts payable clerk, mirroring the same role-based controls the organization already enforces for human users.

Policy violations. If the neural confidence score falls below the configured threshold, or if the action triggers a compliance rule exception, the tier escalates regardless of the base score.

Agent Evolution: Earned Autonomy

Agents do not stay at the same tier forever. An agent that consistently operates without incidents earns more autonomy. An agent that triggers violations loses it.

Agents classified in lower tiers based on their track record get promoted: fewer review requirements, higher auto-execution thresholds. Agents with policy violations or elevated error rates get demoted: tighter controls, lower thresholds, more frequent review.

This is not theoretical. We track it across all 385+ agents in production. An SAP invoice processing agent that runs 500 successful 3-way matches without a single exception gets its Tier 2 actions re-evaluated for potential Tier 1 promotion. A Salesforce deal routing agent that misroutes two opportunities in a month gets its Tier 1 actions temporarily elevated to Tier 2 with mandatory review.

The promotion and demotion logic is deterministic, not discretionary. The governance team sets the criteria; the system applies them automatically.

Metrics That Keep Tiering Honest

Risk tiering only works if you measure whether the tiers are correctly calibrated. Three metrics matter most:

Governance overhead: target less than 5%. This is the percentage of total agent processing time spent on governance activities, approvals, reviews, audit logging. If governance consumes more than 5% of processing capacity, your tiers are too conservative or your approval workflows are too slow.

False positive rate: target less than 15%. The percentage of Tier 3 actions that reviewers approve without modification. If more than 15% of blocked actions turn out to be perfectly fine, your scoring model is over-classifying risk and creating unnecessary friction.

Override rate: target less than 5%. The percentage of governance decisions that human operators override. High override rates mean the rules engine and the humans disagree about risk, which means either the rules are wrong or the humans need recalibration on policy.

If your governance overhead exceeds 5%, start by examining whether Tier 2 review windows are creating queues. If your false positive rate exceeds 15%, your scoring thresholds need adjustment, likely the Tier 2/Tier 3 boundary. If overrides exceed 5%, audit the specific rules being overridden and determine whether the rule or the override pattern is correct.

Where to Go Next

• Agent Governance Risk Matrix Tool — interactive tool to score and classify your own agent actions across the four dimensions
• Enterprise Agent Governance Checklist — the operational checklist for standing up governance around tiered agents
• HITL Governance Design Patterns — approval gates, review queues, and escalation paths for each tier

Bottom Line

Risk tiering is not about limiting agents. It is about giving each agent action exactly the right level of autonomy and oversight based on what can actually go wrong. Score across four dimensions, map to three tiers with concrete control patterns, let agents earn their way to more autonomy through track record, and measure whether your tiers are calibrated correctly. That is how you move from "AI is too risky" to "AI is appropriately governed" with 385+ agents running in production across your enterprise stack.