Guardian routing by agent action risk

AgentTrust ID uses risk-based routing for AI agent authorization. A read action should not pay the cost of a database delete, and a destructive action should not pass through the read path. The Guardian pipeline classifies each action as read, mutating, destructive, or admin, then sends it to the guard path that matches that effect.

Risk-based routing

Risk-based routing means the action effect decides the authorization path. The platform does not run every request through every guard. It checks the request, classifies the effect, and routes it.

The current classifier uses explicit effects when the caller or tool definition provides one. If no effect is supplied, it classifies from the action name. Names that contain get, list, read, search, or fetch become read. Names that contain write, update, create, send, deploy, or similar verbs become mutating. Names that contain delete, drop, destroy, purge, terminate, remove, or truncate become destructive. Admin patterns include admin, transfer_ownership, revoke, grant, impersonate, and escalate.

Unknown actions default to mutating. That gives the request a stricter path than a read.

Flat check risk

A flat check creates one of two problems.

If every action gets a shallow check, destructive actions can pass without enough review. If every action gets a deep check, reads take unnecessary latency and cost. Agent systems need both speed and control because a session can move from a read to a write to a delete.

The route matters most when something is degraded. In AgentTrust ID, destructive and admin actions fail closed if the Guardian router is missing or unavailable. A read can still clear Fast Guard. A production delete cannot rely on that fallback.

Routed check example

The public Python SDK sends action checks through the same API request. The caller can pass an effect when the tool definition already knows it.

from agenttrustid import AgentTrustClient

client = AgentTrustClient.from_env()

agent = client.agents.create(
    name="ops-assistant",
    framework="custom",
    capabilities=["tickets:read", "tickets:update", "db.drop_database"],
)

read_decision = client.actions.check(
    agent_id=agent.id,
    tool_name="tickets:read",
    tool_input_summary="Read the open support ticket.",
    action_effect="read",
)

write_decision = client.actions.check(
    agent_id=agent.id,
    tool_name="tickets:update",
    tool_input_summary="Mark ticket as waiting on customer.",
    action_effect="mutating",
)

delete_decision = client.actions.check(
    agent_id=agent.id,
    tool_name="db.drop_database",
    tool_input_summary="DROP DATABASE production",
    action_effect="destructive",
)

for decision in (read_decision, write_decision, delete_decision):
    print(decision.allowed, decision.guard_tier, decision.reason)

Read actions go through Fast Guard. Mutating actions use Fast Guard as a prefilter and then use the Guardian router when it is available. Destructive and admin actions use Fast Guard first, then the Guardian path. If that path is missing, the response denies the action with a reason.

Prevention

Declare the effect at the tool boundary when you can. Name-based classification is better than treating unknown tools as reads, but it is still a fallback. A tool registry should mark email.send as mutating, db.drop_database as destructive, and iam.grant_role as admin.

Then test all four effects. A test suite that checks only read actions can miss the branches that matter during an incident. Tests should assert the decision, guard_tier, and reason for reads, writes, destructive calls, and admin calls.

Solving this with AgentTrust ID

AgentTrust ID gives every supported surface one routing model. MCP tools, A2A handoffs, and API calls are translated into one authorization request with an action name, effect, source, session, agent, and org. The Guardian pipeline makes the decision from that request.

This connects to read-only sessions. A mutating action in a read-only session returns elevation_required and an approval_id. Destructive and admin actions need stricter behavior: if the Guardian path is unavailable, the system must deny instead of falling back to a shallow check.

To route tool calls by action effect, start with the SDK guide. To talk through risk tiers for your agents, join the waitlist.

• Read the SDK guide
• Join the waitlist