Security · 2026-03-19

The Identity Stack for Autonomous Commerce: When Your AI Agent Needs a Credit Line

By J. W. Bouckaert

The agent that bought a server farm

Consider an autonomous procurement agent acting for a mid-market SaaS company. It has valid API credentials and tokens scoped to "infrastructure procurement." Its spending limit, through a misconfigured policy, applies per transaction rather than per period. In 90 seconds it places 14 orders for GPU compute capacity totalling $340,000.

No human reviews the purchases. No human is notified until the invoice arrives. The credentials are valid, the transactions are authenticated, and every audit log entry shows a clean chain of authorization.

The agent does exactly what it was authorized to do. The problem is that "authorized" and "appropriate" have diverged, and the identity infrastructure has no mechanism to detect the gap.

The example is illustrative, and every step in it is something today's credentials allow. The identity industry has spent two decades building systems that answer the question "Is this human who they claim to be?" It has not built systems that answer the question "Should this machine be doing what it is about to do?"

The liability vacuum

When a human employee exceeds their purchasing authority, the legal framework is settled. Agency law, employment contracts, corporate governance policies, and insurance coverage all provide clear allocation of liability. The employee acted outside their authority. The employer bears liability to the counterparty under apparent authority doctrine. The employer may seek recourse against the employee. Insurers adjudicate claims under existing policy language.

When an AI agent exceeds its intended authority, none of these frameworks apply cleanly.

Agency law requires a principal-agent relationship. The Restatement (Third) of Agency (2006) treats a computer program as an instrumentality of the person who uses it, not as an agent (section 1.04, comment e). Courts have not settled how that applies to AI systems that act with little human direction, so the allocation of liability for an autonomous transaction is still open.

Smart contract execution is not the same as legal authorization. An agent may have valid cryptographic credentials to execute a transaction while simultaneously lacking the legal authority to bind its principal to the resulting obligation. Technical authentication and legal authorization are orthogonal—and current identity systems conflate them.

Insurance policies were not written for autonomous actors. Commercial general liability, errors and omissions, and cyber insurance policies contain exclusions and definitions that assume human decision-making in the chain of authorization. An AI agent that autonomously commits to a financial obligation may fall outside coverage entirely.

The result is that every organization deploying AI agents with financial authority is operating with unquantified liability exposure. The identity layer is the only infrastructure positioned to close this gap—but only if it is redesigned for machine-to-machine trust rather than human-to-service authentication.

Limits of OAuth scopes

The reflexive response from most identity architects is that OAuth 2.0 scopes solve this problem. They do not.

OAuth scopes define what a client can access. They do not define how much, how often, under what conditions, or with what behavioral constraints the client should exercise that access. A scope of payments:write grants permission to create payments. It says nothing about:

• Velocity constraints. How many payments per minute, hour, or billing cycle?
• Value constraints. What is the maximum single-transaction value? What is the aggregate commitment ceiling?
• Behavioral baselines. Is the current transaction pattern consistent with the agent's historical behavior?
• Contextual conditions. Is the agent operating during expected hours, from expected network origins, against expected counterparties?
• Temporal decay. Should the agent's authority diminish over time without explicit reauthorization?

OAuth was designed for a world where a human sits at the end of every authorization chain, providing implicit behavioral constraints through their own judgment. Remove the human, and the scope model becomes a blunt instrument—a binary gate that is either open or closed, with no gradient of trust between the two states.

The agent delegate

PasskeyBridge models an agent's authority as an agent delegate rather than a bare API key. An organization admin creates the delegate, and the record holds:

1. The delegated scopes. What the agent may do, with the original list kept so that narrowed scopes can be restored.
2. A trust score and a revocation floor. The score starts at 1.0 unless the admin sets a lower starting value, and the delegate is deactivated when its score falls below the floor (0.2 by default).
3. An optional expiry. Up to one year. After it, the agent's token no longer verifies.
4. The delegating account. The account ID of the admin who created it, which traces the agent's actions back to a person without putting that person's name or email on the record.

The delegate does not carry transaction-value ceilings, velocity caps or spending budgets. Those belong to the system that executes the payment. The agent receives a random token, shown once, and PasskeyBridge stores only its SHA-256 digest.

Delegate creation

When an admin delegates authority to an AI agent, PasskeyBridge creates a record with the following fields:

The record is a row in shield_agent_delegates. When the agent presents its token, PasskeyBridge hashes it and looks up an active, unexpired delegate with that digest.

Behavioral trust decay

Static authorization is the root cause of the procurement agent scenario described in the opening. The agent had valid credentials with no mechanism for those credentials to weaken as behavior diverged from expectations.

PasskeyBridge scores agent behavior with its "Governor" trust engine. The engine re-scores a delegate from its recent activity when a soft signal arrives for the organization, when a refused agent call is recorded, in a five-minute sweep of new activity, or on request, and the trust score falls or recovers accordingly.

The trust score

Each delegate has a trust score between 0.0 and 1.0, starting at 1.0 by default. The detectors that lower it are:

• Velocity. More than 50 actions in five minutes.
• Error bursts. More than 10 failed actions in two minutes.
• Scope violations. Attempts to act outside the delegate's scopes.
• Network rotation. More than five distinct network origins in ten minutes. Origins are compared as keyed IP digests, and the addresses themselves are not stored.
• A burst after silence. Activity resuming after more than 24 hours with none.

An assessment from the intelligence worker can lower the score but never raise it. A clean evaluation, with no negative signal, adds 0.05.

Graduated response

The trust score maps directly to operational authority:

These are the platform defaults, and an organization can move the full and read-only thresholds. When trust drops below the floor, the delegate is deactivated, and any negotiation it is part of is revoked at its next renewal. A hard signal such as a SIM swap goes further: the parametric cascade deactivates the organization's agent delegates, revokes its open A2A negotiations and freezes the affected shadow identities in parallel, inside the request that carried the signal, and the organization's playbook can also tear down BLAST tunnel sessions.

This is the critical difference between an identity system designed for autonomous agents and one adapted from human authentication. The human system asks "Is this credential valid?" and returns a binary answer. The agent system asks "Is this behavior consistent with the authority that was granted?" and returns a gradient—with automated enforcement at every threshold.

Agent-to-agent trust negotiation

Autonomous commerce does not involve a single agent acting in isolation. It involves networks of agents negotiating with each other—a procurement agent negotiating with a supplier's pricing agent, a logistics agent coordinating with a carrier's scheduling agent, a compliance agent verifying that a counterparty's agent meets regulatory requirements.

Each of these interactions requires mutual trust establishment. PasskeyBridge implements this through the A2A (Agent-to-Agent) negotiation protocol:

1. Initiation. A caller in the organization names the initiating and responding delegates, both in that organization, and a lifetime for the negotiation.
2. Attestation. Both delegates must be active, each delegating account must hold a passkey credential, the delegates' certificates are verified, and neither delegating account may have had a hard signal in the last five minutes.
3. Trust coefficient calculation. The Combined Trust Coefficient (CTC) is the geometric mean of the two delegates' trust scores, adjusted for reported network jitter, a device-binding bonus and the freshness of a SIM signal.
4. Scope intersection. The negotiated session is limited to the intersection of both delegates' scopes, further narrowed by the CTC.
5. Signing. Each step that changes the negotiation is signed with a hybrid HMAC-SHA-256 and ML-DSA-65 signature and committed together with its proof.

The negotiated session has its own expiration (10 seconds to one hour, 60 seconds by default) and its own transaction limits, independent of either agent's individual delegation certificate. Its coefficient is computed once, at negotiation, and does not decay with time. A hard signal against either agent invalidates the negotiation, and a renewal is refused when the agents' current scores have drifted more than 0.10 from the negotiated coefficient.

The commerce stack

For autonomous commerce specifically, this architecture provides a complete trust stack:

The delegate record names the delegating person only by account ID, without a name or email, and the agent's token is stored only as a digest. The audit trail records IDs, digests, scores and timestamps, never names or email addresses. Account IDs and digests are pseudonymous identifiers, and they are still personal data under GDPR.

The credit line

The title of this article poses a specific question: what happens when an AI agent needs a credit line? The financial services industry is beginning to confront this question directly, and the answer requires every layer of the stack described above.

A credit line is a legal instrument, not merely an authorization to spend. It creates an obligation on the part of the borrower and an exposure on the part of the lender. Extending a credit line to an AI agent requires answering questions that existing identity infrastructure cannot address:

Who is the borrower? The agent is not a legal person. The delegating principal is the borrower—but the delegation must be cryptographically provable, not merely asserted.

What are the terms? The credit facility must encode parametric constraints that mirror the delegation certificate: maximum draw, velocity limits, permitted categories of expenditure, temporal bounds.

How is risk assessed? The agent's behavioral trust score becomes a real-time credit risk signal. A trust score of 0.95 with stable behavioral patterns represents a different risk profile than a trust score of 0.65 with declining trajectory.

How is the facility revoked? If the agent's behavior degrades, the lender freezes the credit line when PasskeyBridge reports the delegate deactivated or a hard signal arrives. PasskeyBridge does not see the draws, so the lender's system has to act on that signal.

Agent delegates, behavioral trust scoring, the hard-signal cascade, A2A negotiation and hybrid signatures run in PasskeyBridge's production infrastructure today. A credit-line integration does not exist yet. It would consume these same signals.

Three structural shifts

The identity industry must make three structural shifts to support autonomous commerce at scale:

From binary to gradient trust. Authentication cannot remain a yes/no gate. Every agent interaction must produce a trust score, and that score must have real-time consequences on the agent's operational authority.

From static to decaying authorization. Every delegation must include temporal bounds and behavioral baselines. Authority that does not decay is authority that cannot be governed.

From human-centric to principal-centric liability. The identity layer must keep a link from every agent action back to the person who authorized the delegation, without storing that person's name or contact details. That link is what lets liability be attributed while the records stay minimal.

The procurement agent in the opening example does not fail because of a technology gap. It fails because its identity infrastructure was designed for humans making purchasing decisions and machines executing them.

Governing agents that buy things needs scoped delegates, trust scores that respond to behavior, fast revocation, and a record that traces each agent to the person who authorized it.

Start free · Test the API