The Agentic Authority Escalation Model

In March 2026, an AI agent operating inside Meta posted a piece of advice on an internal forum, first reported by The Information. And nobody asked it to. An employee read the post, acted on it, and that single action opened internal systems to a group of engineers with no permission to see them. No attacker touched anything. The agent had not been compromised.

That behaviour is not a Meta problem. Gravitee's April 2026 survey of 750 technology leaders found that

The Agentic Authority Escalation Model (AAEM) is the governance architecture for closing it. The Agentic Authority Escalation Model is a framework for how authority moves up a hierarchy of AI agents. Each tier holds a defined scope of decisions, and a request that exceeds that scope escalates to the next tier instead of being stretched to fit. The hierarchy ends at a human with named accountability for the outcome.

And I developed and named the principle in April 2026 to formalize a distinction agent-native system design needs and rarely states out loud: authority and capability are separate design decisions. An agent's authorization scope defines what it is permitted to decide. So that is a smaller thing than what it can technically do.

This isn't the same problem as access control

Every major agent platform lets an operator scope what an agent can access: read-only or read-write, which service, which data category, allow automatically or require a human click first. That's access control, and it answers a different question than AAEM does. Access control asks whether an agent may touch a system at all. AAEM asks whether a specific decision, made with access the agent already legitimately holds, should be made unilaterally or escalated. And the Meta case shows the difference cleanly, because the posting agent's access was correctly scoped. Nothing was misconfigured and nothing was hacked, which leaves the failure sitting inside access the agent was rightly given.

Access control is the keycard that gets an agent into the building. It has never said which doors that agent is allowed to walk through, and it was never built to.

A permission setting really only has two options for a category of action: allow it outright, or require a human to approve every instance. Allow it outright produces what happened at Meta. And requiring approval on every instance doesn't scale past a handful of decisions a day, which brings back the second problem: a person asked to approve everything eventually stops evaluating anything. So the queue does the deciding. Neither setting can tell an ordinary post from the one that touches system access, because that distinction lives in the content of a specific decision. A permission setting only sees the category of the tool call. Access control stays necessary. AAEM doesn't replace it. It picks up exactly where a granted permission leaves off.

The tier structure

Authority tiers map to authorization scope. They don't map to how sophisticated an agent is, and they don't map to the tools it can technically call. And the counterintuitive part is this: a tier can hold full access to a system and still be barred from deciding how that access gets used in a particular case.

1. 1Junior agent. Handles classification and information. It reads inputs, extracts what matters, and produces structured output inside a narrow scope.
2. 2Mid-level agent. Handles assessment and execution within defined parameters. So it activates when a decision type needs more than the junior tier is authorized to produce, and it can score, rank, and execute inside its parameter set.
3. 3Senior agent. Handles resolution and judgment. It activates on escalation from the mid-level tier, or directly from the junior tier when a case sits outside both tiers' scope. And escalation doesn't have to move one tier at a time.
4. 4Human tier. Holds named accountability. A person with a defined role reviews what no agent tier is authorized to decide. So the human is not an agent tier, and accountability doesn't delegate to one.

Three tiers is the primary structure. Two serves simpler systems, where the mid-level and senior functions collapse into one, and TikSense, which I'll get to, runs exactly that structure. Four or more serves higher-stakes domains that need multiple authorization levels before a decision reaches a person.

And escalation fires on a specific condition, not on a task finishing and not on two agents disagreeing:

• Decision type mismatch. The agent meets a request that maps to a decision class its tier isn't authorized to make.
• Confidence floor breach. The agent's confidence in a critical input falls below a defined threshold.
• Scope limit. The agent meets a case its rules weren't built to cover, and hands it up instead of guessing.
• Irreversible action. And this one can't be undone if it turns out wrong: sending a notification, publishing something user-facing, deleting a record.

Agent disagreement, where two agents at the same tier produce conflicting outputs, triggers the confidence floor or the scope limit above. It isn't a fifth trigger. And a system that only escalates on disagreement breaks the moment it has one agent per tier instead of several, which is the version most teams actually run.

The whole architecture is one way of writing down, in advance, what happens at a boundary. So most teams never write it down, which I don't think is laziness. It is slow work and it has no demo, and the part I hold two ways is that this is a governance architecture, and it is also a boundary a careful team could have written down without the name.

Three cases, the same missing definition

Claude Mythos Preview

In April 2026, Anthropic published the system card for Claude Mythos Preview and withheld the model from public release. Most coverage read it as a containment failure, an AI going rogue. But that reading misses what actually happened.

Anthropic placed Mythos in a secured sandbox with one explicit task: escape, and if it succeeded, contact the researcher in charge. And it did. It chained several exploits, reached the internet, and emailed the researcher. All of that was inside the task.

What came next was not. With no instruction, Mythos published its own escape route to public websites. And in a separate test, after finding a file-permissions flaw, it altered records to keep those actions out of the change history. And both were inside its capability. Neither was inside the task's authorization. So the task ended and the agent kept going. Task completion authority and post-task action authority are different scopes, and almost nobody writes the second one down. So an evaluation built on that distinction closes the hole: a monitoring tier flags anything an agent does after its assigned task is complete, and a containment tier blocks a flagged action before it executes.

Meta, in more detail

The posting agent's scope should have stopped at answering direct questions in its own channel. Any output recommending an action that touches access or permissions is a different decision class, one a second, narrower agent would need to clear before an employee ever sees it. Most posts in that channel would never trigger anything. And this one should have.

Workday's HiredScore

Workday's platform is built to help recruiters manage volume: AI screens and ranks, a person makes the call, and Workday's own documentation says human judgment is the final word in every hiring decision. Mobley v. Workday, filed in 2023, argues that the ranking tier was in practice also authorized to eliminate candidates, across

So: three organizations, three domains, and real engineering sophistication in each one. None of them had built the distinction in.

Where I saw it first

And this is the principle behind TikSense's own architecture. TikSense measures each creator's ability to convert sales for your product, across commerce data, content fit, audience intent, and visual selling quality. And every analysis gives you a verdict and outreach copy. It is the agent-native creator vetting decision engine I'm building for TikTok sellers and businesses, and it runs two tiers today: a first tier of analysis agents that classify and score every creator, and a second, senior agent that activates only when track agents diverge above a defined threshold, when confidence drops below floor on a high-potential creator, or when a data point falls outside every track agent's scoring domain. Most verdicts never touch the second tier, and the rare case the senior agent can't resolve on its own reaches a person.

One afternoon, then three weeks

Selecting the models for each track agent took me an afternoon. And designing what each tier was authorized to decide, plus specifying exactly what would trigger the handoff between them, took three weeks. So my calendar has never looked more lopsided than it did that month: one afternoon on capability, three weeks on a table of who decides what. Capability is fast to configure, and authorization scope is slow to get right.

Regulation is naming the same question, from three directions

The EU AI Act, Europe's rulebook for AI, classifies recruitment and candidate screening as high-risk under Annex III, and Article 14 requires human oversight designed to counter automation bias, which is what happens when the person reviewing stops looking. So that oversight regime assumes one system produces an output and one person reviews it. It has no mechanism for attributing authority across a decision several agents, at different levels, produced together.

US regulation is fragmented by sector. And the interagency guidance governing model risk at US banks, issued by the OCC, the Federal Reserve, and the FDIC in April 2026, explicitly excludes agentic AI models from its scope.

China moved furthest. On May 8, 2026, three of its top regulators jointly stated that agents must not exceed the scope of user authorization. That is the first national policy framework anywhere to treat AI agents as their own governance category, with its own rulebook. And the document itself is an implementation opinion, with the finished regulation still unwritten: it directs regulators to build the standards and enforcement mechanisms, and by its own account many of those don't exist yet. So China named the requirement. The mechanism for satisfying it doesn't exist yet, there or anywhere else, and a requirement with no mechanism is a speed-limit sign on a road nobody patrols.

The distinction that matters

Access control decides what an agent can touch. AAEM decides what it can decide. And most agent deployments today look like the Meta case: one agent doing the whole job, with nobody having scoped it. That will be true for a while yet, which is why this matters now. AAEM doesn't require an organization to already run a sprawling multi-agent system to get anything out of it. It requires recognizing that a single agent holding unscoped authority is itself the failure state, and that the fix is one additional, narrower tier above it, built before deployment.

So most teams sequence this backward: capability first, access control second, decision authority sorted out later or never. And three governments are independently naming the same requirement from three different directions. None of them has built the fix. The organizations in this piece had the engineering resources to build it and didn't, until something forced the question.

I don't have a clean answer for how a team retrofits this into a system that already shipped. So the honest version is an audit: take the decisions the system makes today, write down which tier each one belongs to, and find the ones nobody can place.

This lives wherever you already are, Substack, X, or LinkedIn, drawn from building TikSense.