PasskeyBridge —

Security · 2026-03-11

A Trust Governor for Autonomous AI Agents

By J. W. Bouckaert

A Trust Governor for Autonomous AI Agents

The password was never designed for this

Passwords authenticate humans. They answer a single question at a single moment: "Are you who you claim to be?" The answer is binary. Yes or no. Allow or deny.

This model works for people because human sessions are episodic. A person logs in, performs a bounded set of actions, and logs out. The authentication decision at the gate is sufficient because the session is short and the actor is predictable.

Autonomous AI agents do not fit that model.

An agent can make many API calls a minute and run continuously for long periods. Its behavior shifts as its context changes. It may interact with other agents, negotiate permissions, and delegate sub-tasks to further autonomous processes.

Checking authorization once, at the start of that lifecycle, leaves everything the agent does afterwards unchecked.

The state machine of identity

Traditional authorization is stateless. A token is issued. The token is valid or expired. There is no middle ground.

The PasskeyBridge Trust Engine replaces this with a trust score and a ladder of states. Each agent delegate has a score between 0.0 and 1.0, and the score decides which of four states it is in. The thresholds below are the defaults; a tenant can move the full-access and read-only rungs, and each delegate has its own revocation floor (0.2 by default):

┌────────────────────────────────────────────────────┐
│              Agent Trust State Machine              │
├────────────────────────────────────────────────────┤
│                                                    │
│   ┌──────────┐    score ≥ 0.7    ┌─────────────┐  │
│   │   Full   │◄─────────────────►│  Read-Only   │  │
│   │  Access  │    score < 0.7    │   (Scoped)   │  │
│   └────┬─────┘                   └──────┬───────┘  │
│        │                                │          │
│        │ score < 0.4              score < 0.4      │
│        ▼                                ▼          │
│   ┌──────────┐                   ┌─────────────┐  │
│   │  Verify  │    score < 0.2    │Auto-Revoked  │  │
│   │   Only   │──────────────────►│  (Terminal)   │  │
│   └──────────┘                   └─────────────┘  │
│                                                    │
│   Hard signal: every active delegate in the tenant │
│   is deactivated (SIM swap or other hard signal)   │
└────────────────────────────────────────────────────┘

This is a governor: a mechanism that adjusts what an agent can do based on what it is doing.

The term is borrowed from mechanical engineering. A centrifugal governor on a steam engine does not decide whether the engine should run. It regulates how fast the engine runs based on feedback. The PasskeyBridge Trust Engine plays the same role for agent delegates.

Allow/deny fails for agents

The binary model fails in three specific ways when applied to autonomous agents:

1. Behavioral drift

A human user's behavior within a session is relatively stable. An AI agent's behavior can change dramatically based on its prompt, its tool access, and the data it encounters. An agent authorized to read customer records at 09:00 might, by 09:15, be attempting bulk exports because its orchestration logic encountered an unexpected pattern.

The PasskeyBridge behavioral trust scoring engine watches the delegate's recorded activity for velocity spikes (more than 50 actions in 5 minutes), error bursts (more than 10 errors in 2 minutes), IP rotation (more than 5 addresses in 10 minutes), scope violations, and a burst of activity after more than 24 hours of inactivity. Each signal lowers the score by a weight scaled to its severity, and normal usage raises it by 0.05 at a time.

2. Scope creep

Static scopes are defined at delegation time. An admin creates an agent with read:accounts and write:transactions permissions. But those scopes do not account for how aggressively the agent exercises them.

An agent making a few write:transactions calls a minute and one making hundreds can both be within scope.

The Trust Engine implements graduated scope narrowing. With the default ladder, when a delegate's trust score drops below 0.7 its write scopes are removed. Below 0.4, only the verify scope remains. Below the delegate's revocation floor (0.2 by default), the delegate is revoked.

Narrowing is recorded and reversible. The original scope list is kept, and if the score recovers above the threshold the scopes are restored. Every narrowing or restore, and every score change larger than 0.05, is written to the append-only audit trail.

3. Cascading compromise

In a multi-agent architecture, compromise propagates. If Agent A delegates to Agent B, and Agent B is compromised, the blast radius extends to every system Agent B can reach.

PasskeyBridge contains this at the tenant level. When Pillar I ingests a hard signal, such as a SIM swap, it sets every active agent delegate in the tenant to a trust score of 0 and deactivates it, and it revokes the tenant's open A2A negotiations. This happens before the tenant's playbook runs.

This is the "hard signal" line in the state diagram. Whatever a delegate's score, a hard signal revokes it, and no tenant setting overrides that.

The score and its signals

The score is a single number between 0.0 and 1.0. Each evaluation starts from the current score and applies the signals found in the delegate's recent activity:

new_score = current_score
          − Σ (signal weight × severity)    velocity, errors, IP rotation,
                                            scope violations, burst after inactivity
          + 0.05 per normal-usage signal    (capped at 1.0)
          − AI assessment (at most 0.3, never below the revocation floor)

An AI behavioral assessment can only lower the score, by at most 0.3, and cannot push it below the revocation floor on its own: only deterministic signals revoke. The engine runs when a soft signal or an AI assessment arrives, when failed calls are recorded, and in a sweep every five minutes. It does not run on every API call.

Carrier signals do not enter the score. They act through the hard-signal path above. NF-08 device checks are separate and do not feed the score either.

The governor's output

A service that receives a request from an agent can call the shield-agent-delegate verification endpoint before processing it. For an active, unexpired delegate the response includes:

  1. Authorized: whether the delegate may act, and for the scope the caller asked about
  2. Agent label: the name the tenant gave the delegate
  3. Effective scopes: the current scope list, which may be narrower than the original delegation
  4. Expiry: when the delegation expires
  5. Trust score: the current score, from 0.0 to 1.0

A revoked or expired delegate returns HTTP 403. Verification is rate-limited, and each call is recorded as delegate activity. See delegating identity to AI agents without delegating trust for the full delegate lifecycle.

The practical difference

Consider a concrete scenario. A fintech company deploys an AI agent to process customer refunds. Under the binary model:

  1. The agent is issued an API key with write:refunds scope
  2. The agent processes refunds autonomously
  3. If the API key leaks, the attacker has unlimited refund authority until someone notices and manually revokes the key

Under the governor model:

  1. The agent is issued a scoped delegate credential with write:refunds scope, time-bound to 8 hours
  2. The refund service verifies the delegate before each refund, and each verification is recorded as activity
  3. When the agent makes more than 50 calls in 5 minutes, the engine records a velocity spike and lowers the trust score at its next evaluation
  4. Once the score is below 0.7, the engine removes the write scopes, so write:refunds is no longer in the delegate's scope list
  5. The narrowing is written to the audit trail, where the security team can review it
  6. Containment comes at the next evaluation, which runs at least every five minutes

In the first model authorization is checked once. In the second it is re-evaluated as the agent works.

Current practice

Autonomous agents are deployed as customer service bots, code generation pipelines, financial analysis systems and supply chain optimizers. Each needs an identity, and each can be compromised.

The identity industry's response so far has been to give agents API keys, OAuth tokens, or service accounts, the same mechanisms designed for human-initiated, session-bounded interactions.

Autonomous agents need authorization that changes with their behavior after the token is issued.

PasskeyBridge's Trust Engine does this for agent delegates: it scores recorded behavior, narrows scopes as the score falls, restores them when it recovers, and revokes every delegate in the tenant on a hard signal.

Explore the Trust Engine → | Read the A2A Trust Protocol → | Start building →

Start free · Test the API