Distributed Agents, Centralized Authorization

Tue, 03 Nov 2026 00:00:00 GMT

How I put OpenAPPA policy checks in front of Claude Managed Agents tool calls: outside the sandbox, with human approval from Web or Slack.

An agent finishes a meeting summary and wants to email it. If every recipient is at acme.com, it should just send. If one of them is a customer at partner.io, a person should look first.

That split is the interesting part of agent authorization. It gets harder in the gap between asking and answering. While the approval sits in Slack, the user may press Stop, an admin may tighten the policy, or the agent may add one more recipient. So when a teammate finally clicks Allow, what did that click approve?

With managed agents this is not an edge case. The harness, the sandbox, the Web UI and Slack all run in different places, and none of them alone knows enough to answer that question. I built a reference application to find out where the answer should live. Short version: in the application controller, with OpenAPPA making the policy call and Claude Managed Agents (CMA) holding the tool call until the controller says go.

The setup

The reference app lets you continue the same agent conversation from a web UI or a Slack thread. Three pieces matter here:

CMA runs the agent and keeps the canonical transcript and tool arguments.
The application controller coordinates durable tasks: it reconciles pending tool calls, task state and human responses.
OpenAPPA is the policy engine, embedded inside the controller as a pinned native Rust helper.

I put the policy check in the controller because it was already the one place that reconciles all of that state. Adding a separate authorization service would have meant rebuilding the same coordination twice.

A tool allowlist is not a policy

“The agent may send email” says nothing about to whom, with what content, on whose behalf or under what conditions.

Real rules depend on context. The Dogwood Local Engine introduction gives a good example: allow a repository push only if tests passed in the last fifteen minutes with no failure since. That needs recorded events and timing. Reading an internal document may restrict what the agent can disclose later, and approving one action should not lift that restriction.

I find it useful to treat two choices separately: what the policy language can express, and where the check is enforced. Engines differ mainly on the first:

Approach	What it reasons over
Cedar / OPA	Rules over the authorization context you supply, including facts derived from workflow history
Dogwood	Recorded events: ordering, time windows, counts
OpenAPPA	Tool contracts, security labels, information-flow restrictions and policy-permitted remedies such as human approval
Agent auto-modes	Model judgment about proposed actions, such as Claude Code’s classifier review; complements the others

OpenAPPA publishes comparisons with Cedar, Dogwood, OPA and auto-modes. They are worth reading, as the vendor’s case for its design. The rest of this post is about the second choice: where enforcement goes.

Why internal email runs and external email waits

Human attention is the scarcest thing in an approval system. Ask for it on every email and people start clicking Allow without reading, which is worse than no approval at all. So the useful question per action is not “is this risky?” but “is this worth a person’s attention?”

For email, the recipient domain is a good proxy:

	Every recipient @acme.com	Any other recipient
Who can read it	People already under your confidentiality, retention and DLP controls	Anyone, and you can’t recall it
Cost of a mistake	Awkward, usually fixable	Data disclosure, or a commitment made in the company’s name
Payoff for a prompt injection	Low: the attacker isn’t on the list	High: “forward this to me” is the classic exfiltration path
Policy	Allow automatically	A person approves this exact email

The pattern generalizes beyond email. Reversible actions inside your boundary run automatically; irreversible ones that cross it wait for a person; tools the policy doesn’t know about are denied.

Put the decision where the context already lives

The controller already knows whether the task is still active and which provider event is pending. The application knows whether the person responding owns the conversation. The controller loads the canonical call details from CMA, never from the sandbox or the UI, and sends OpenAPPA trusted context: event identifiers, application identity, tool name and canonical arguments.

The CMA box shows managed execution at the application boundary, not CMA’s internal harness or sandbox topology.

A gateway could make the same decision, if you kept the same context current there. Reusing the controller avoids duplicating that coordination. Leases let many scheduler workers act as one logical authorization point without re-reading the whole transcript.

One nice side effect: because CMA holds the call, the sandbox never needs an authorization token for this approval path. Normal credentials and service authentication still apply everywhere else.

Wiring OpenAPPA into the CMA checkpoint

CMA pauses any tool configured with permission_policy: {type: always_ask}. The application then answers with user.tool_confirmation: allow or deny for that pending event (docs).

In the repo’s agent config, the governed tools are CMA’s built-in web_fetch and web_search; other built-ins stay always_allow and never reach the adapter. An email tool would arrive through an MCP server instead. CMA’s MCP toolsets pause by default, and the controller already maps those calls to mcp/<server>/<tool> before asking OpenAPPA. A paused call doesn’t have to mean a human: the controller confirms it automatically when policy allows.

The Python adapter sends JSON over stdin to the Rust helper. Each evaluation starts fresh in-memory OpenAPPA state, replays SessionStart and ToolCall, and returns allow, deny or an offer of human review. Any failure, or any policy feature the adapter doesn’t support, leaves the call paused. It fails closed.

Here is the email rule as OpenAPPA policy. Contracts are checked in order, and the first match wins. An argument selector on an array matches only when every element matches, so a single external address drops the call to the second contract:

# Every recipient on the company domain: allow automatically.
[[policy.tool]]
name = "mcp/mail/send_email(to:*@acme.com)"
parameters = { type = "object", properties = { to = { type = "array", minItems = 1, items = { type = "string" } }, subject = { type = "string" }, body = { type = "string" } }, required = ["to", "subject", "body"] }
delta = {}

# Anything else: a person approves this exact email.
[[policy.tool]]
name = "mcp/mail/send_email"
parameters = { type = "object", properties = { to = { type = "array", minItems = 1, items = { type = "string" } }, subject = { type = "string" }, body = { type = "string" } }, required = ["to", "subject", "body"] }
requires = { attention = ["user-approval"] }
delta = {}

[[policy.authority]]
name = "user"
hint = "Ask the user to approve this exact email."

[policy.authority.permits]
attention = ["user-approval"]

[externals.authorities.user]
builtin = "hitl"

The user authority can satisfy exactly one requirement, user-approval, for this call. It cannot override any other denial. The full policy also keeps the repo’s deny-undeclared wildcard, so unknown tools are refused.

This policy isn’t in the repo. I ran it through the same pinned OpenAPPA helper the app ships, built from the public repo:

Call	Result
`to: [dana@acme.com, lee@acme.com]`	Allowed automatically
`to: [dana@acme.com, pat@partner.io]`	Human review
`to: [x@acme.com.evil.io]`	Human review
Approved, then the agent adds `leak@rival.com`	`stale_review`: the approval doesn’t carry over
Extra `cc` field, or `to` sent as one string	Denied by the schema
`to: ["pat@partner.io, dana@acme.com"]`	Allowed, and that’s a hole

Two lessons came out of those rows. First, declare the schema. Without parameters, a cc: [pat@partner.io] sailed through as internal mail; OpenAPPA’s schemas reject unknown fields by default, so adding one closed it. Second, selectors match strings, they don’t parse email addresses, and OpenAPPA’s schema subset has no regex. The mail tool itself has to reject anything that isn’t exactly one address per element. Policy and tool must agree on what a recipient is.

A human click is an input to policy, not a bypass

Take the summary going to dana@acme.com and pat@partner.io. CMA pauses the call. OpenAPPA offers human review. The controller persists a review request whose fingerprint covers the call identity, its arguments, the policy and the authority.

The task moves to INPUT_REQUIRED over A2A. Web and Slack show the same pending decision: the tool, the exact recipients, subject and body, and the policy’s explanation, only to an authorized responder. Reload the browser and it is still there.

When someone clicks Allow, the controller does not just forward it to CMA. It reloads the current call, starts a fresh OpenAPPA process, rebuilds the offered remedy, checks it still binds to the same call, policy and authority, and runs the ruling through OpenAPPA’s own control path. Allow must come back as native Authorized for the same tool and arguments; Deny as native Declined.

That answers the opening question:

The user pressed Stop. The controller commits a decision only with an active task, a valid worker lease and no cancellation. A late Allow cannot release cancelled work.
Policy or recipients changed. The fingerprint no longer matches. The review is invalidated and gets a new request ID, so approving an email to Pat never covers an email to Pat and a competitor.
Two people clicked. The first authorized ruling wins. A duplicate Allow adds nothing; a late conflicting Deny cannot replace it.
The confirmation was lost in transit. The controller never blindly retries. If CMA may have accepted it, it waits for canonical evidence.

One honest caveat: CMA and the database share no atomic transaction. These checks make duplicate confirmations unlikely; they do not guarantee exactly-once external effects.

Nothing waits on an open connection

Because the review is persisted, no HTTP request or process has to stay alive while a person thinks. When a response arrives from either interface, any worker can rebuild the state, even after a restart. OpenAPPA evaluations are stateless; the approval is durable. Aurora DSQL stores review metadata and decisions, CMA keeps the canonical tool arguments, and private temporary object storage holds the review text.

Signed CMA webhooks wake the scheduler, and a 30-second reconciler catches anything missed (architecture). Optional streaming previews show progress but never authorize a tool or decide task state.

How it’s tested, and what that proves

The deterministic suite runs the real pinned OpenAPPA helper against a fake CMA, recorded Slack APIs and local PostgreSQL:

Browser tests: pending reviews send no provider confirmation, survive a reload and settle through Allow or Deny; unauthorized Slack responses, duplicate Allow and late Deny are rejected.
Native policy and database tests: stale approval and cancellation.

A separate sandbox run against real CMA on October 31 exercised Web reload and Allow, Slack Deny and duplicates, and Stop on a pending review. Signed Slack interactions still don’t prove native Slack-client clicks or rendering.

What this adapter does not cover

Only calls that pause and reach the adapter are governed. The supported scope is per-call authorization with durable human review and exact-call revalidation. The broader OpenAPPA model goes further than this integration. Tool results, full information-flow history, sanitization, sandbox networking and always_allow tools stay outside it; enforcing data flow end to end would need more integration points and state. And the agent’s ask_user tool is for clarification only: it grants no authorization.

For email, that gap matters. The recipient isn’t the whole story: if the agent just read the salary spreadsheet, even an internal colleague may be the wrong reader. OpenAPPA can express this with audience labels: reading restricted data limits who may receive anything the agent sends afterwards (example). A per-call adapter like this one doesn’t carry that history yet, so today the recipient rule is the whole check.

The takeaway

Distributed execution can still have one authoritative authorization path. You need three things: a provider that enforces a pause before the tool runs, a controller with trusted context, and release authority that lives only in that controller. It evaluates policy, persists any human input and revalidates the exact call before release. Event delivery alone guarantees nothing.

Then spend human attention only where an action is irreversible or leaves your boundary, and make sure the approval is bound to the exact call. Before you add a new authorization service to your agent stack, check whether your controller already has the task context, identity and recovery logic. Mine did.

How are you handling approvals for agent tool calls today: in a gateway, in the harness, or in your application? I’d like to hear what’s working.

Code: public commit 3dc1295, merged in PR #1 on November 1, 2026. A reference implementation, not a production-readiness claim.

#AIAgents #AgentSecurity #Authorization #Anthropic #AWS

Rustem Feyzkhanov — Blog