Designing Secure Agent Transaction Infrastructure

At a Glance

This is a conceptual target design, not a deployment topology. The implemented portfolio package is the public research artifact: its reference model, diagrams, control matrix, article series and privacy-safe source-request journey. The transaction infrastructure described below is proposed architecture. It is not presented as a deployed customer system, a production service, a certification or a benchmark result.

The Trust Gap Between Tool Access and Authority to Transact

Giving an agent a tool answers one technical question: can this process call an interface? It does not answer the more important governance questions: who authorized this exact action, under which limits, for which destination, for how long, and what should happen if the outcome is unclear?

That distinction becomes critical when an action creates an external commitment. A purchase, booking, paid API request, subscription change or infrastructure order can consume money, create liability, disclose data or alter an operational state. Authentication alone proves an identity. A broad role or tool permission says what that identity may generally attempt. Neither necessarily proves that a human approved the exact transaction now being committed.

The target design therefore treats a model-generated plan as a proposal. The proposal must cross deterministic boundaries before it can become executable authority. Those boundaries make the actor, transaction terms, policy version, approval, workload, credential use and outcome independently inspectable.

Probabilistic Planning, Deterministic Controls

An agent coordinator is useful because it can interpret an objective, gather context, compare options and propose a sequence. Those tasks can tolerate probabilistic reasoning. Final authorization cannot.

The design separates the two modes:

• The agent coordinator creates a typed proposal and may explain why it selected that proposal.
• The policy decision point evaluates explicit fields and current policy state without asking the model whether its own action is allowed.
• The approval or delegation boundary determines whether the exact proposal has valid human consent or falls inside a bounded standing authority.
• The grant issuer creates only the authority required for one execution context.
• The isolated executor performs the external action without giving provider credentials to the model.
• The reconciler decides what to do when a provider response is incomplete or ambiguous.

This follows the least-agency direction in OWASP guidance on excessive agency: minimize tools, permissions and autonomous high-impact actions, and add human approval where consequences demand it. The architecture does not claim that one pattern removes every risk. It creates explicit places where risks can be denied, contained, observed and tested.

Standards references last reviewed: 17 September 2026.

Goals and Non-Goals

The target architecture is designed to:

• bind authority to a typed action rather than a conversational impression;
• preserve a meaningful distinction between the human, agent, runtime workload and downstream credential;
• support exact approval and bounded delegation without turning either into a reusable bearer permission;
• keep provider secrets outside prompts, traces and agent-visible memory;
• make authorization consumption, idempotency and evidence part of one internal commit boundary where feasible;
• refuse to guess after an ambiguous external response;
• preserve an inspectable chain from instruction to reconciled outcome.

It does not attempt to:

• guarantee exactly-once execution across an independent external provider;
• replace the provider's own authorization, fraud or compliance controls;
• claim production readiness, certification, regulatory approval or universal protocol conformance;
• publish a private implementation topology, storage layout, API surface, vendor configuration or deployment model;
• claim lower latency, higher throughput or greater security than another system without reproducible evidence.

Target Reference Architecture

The architecture is a control plane around an external action, not a wallet interface around a model. Human intent enters on the planning side. Provider credentials exist only at the execution edge. Policy, approval, grant issuance, outcome handling and evidence sit between them.

The core responsibilities are intentionally generic:

1. Human principal states the objective and supplies exact approval or a bounded delegation.
2. Agent coordinator gathers context and proposes typed terms but holds no final authority.
3. Policy decision point evaluates identity, action, target, limits, freshness and current policy version.
4. Approval and delegation service verifies consent for the exact proposal or proves it falls within standing authority.
5. Grant issuer creates a short-lived, least-privilege execution grant.
6. Credential broker keeps the downstream credential outside model-visible state.
7. Isolated executor performs only the action named by the grant.
8. External provider accepts or rejects the request and supplies outcome evidence.
9. Outcome reconciler resolves confirmed, denied, failed and uncertain results.
10. Evidence ledger links each decision and artifact without storing the provider secret.

Four Identities That Must Stay Distinct

Collapsing identities makes audit trails look simpler while weakening the questions they can answer. This design keeps four identities explicit:

The grant should name the workload and intended audience. The broker should release a credential only after verifying those bindings. The evidence record should preserve which human, agent and workload participated without copying the downstream credential into the audit trail.

Governed Transaction and Data Flow

The canonical flow is:

1. A human supplies an instruction or bounded delegation.
2. The agent creates a typed proposal with an action, target, constraints and unique request identity.
3. Deterministic policy evaluates the proposal and records its policy version and reason.
4. The proposal either fails closed, proceeds under valid delegation or requests exact approval.
5. The authorization boundary consumes the approval or delegation, applies any budget reservation and issues a scoped grant.
6. The isolated executor presents that grant to the credential broker.
7. The broker releases only the required downstream credential inside the execution boundary.
8. The executor submits the authorized request to the provider with an idempotency strategy appropriate to that provider.
9. A definitive response closes as confirmed, denied or failed. An ambiguous response closes as uncertain, not as a retryable generic error.
10. Reconciliation uses provider evidence and local request identities to establish the final outcome.
11. The evidence chain links the instruction, proposal, policy decision, approval or delegation, grant, provider reference, receipt and reconciliation record.

The important data-flow property is directional: transaction context moves toward authorization, and a scoped decision moves toward execution. Provider credentials do not flow back into planning context.

Exact Approval and Bounded Delegation

An approval prompt is useful only when the user can understand what will happen and the system can prove that the committed action matches what was shown. The approval envelope therefore binds, at minimum:

If a bound term changes, verification rejects the commit and returns the proposal to policy evaluation or fresh approval. A standing delegation follows the same principle: it defines a constrained set of acceptable transactions, not a blank instruction to “buy what is needed.”

What Exactly Did the Human Approve? explores presentation, binding and delegation in more detail.

Seven-Control Security Matrix

The visual is a summary; the table below is the authoritative, searchable version. “Evidence status” remains Target because these controls are proposed for the reference design rather than asserted as production-verified behavior.

This matrix deliberately avoids a numeric security score. Security depends on correct implementation, operational controls, threat model and validation—not the number of rows in a diagram.

Credential Isolation at the Execution Edge

The agent needs enough context to propose a transaction; it does not need the secret that commits it. The target broker accepts a scoped grant, verifies its workload, audience, tenant, action and expiry, and releases only the credential required for that execution context.

Three rules follow:

• A downstream credential never appears in the prompt, conversation transcript or model-visible scratch state.
• The executor cannot ask for an arbitrary credential; the grant and broker policy constrain the selection.
• Credential material is not copied into the evidence record. The record keeps an opaque reference and the decision facts needed for inspection.

This reduces the consequence of prompt injection and accidental logging, but it is not sufficient alone. The isolated runtime, broker authentication, secret lifetime, provider controls and monitoring still require their own threat analysis and tests. Keeping Provider Credentials Outside the Agent covers those checks.

Authorization Consumption, Idempotency and the Commit Boundary

The strongest internal boundary groups the state changes that must agree: consume the approval or delegation, reserve any relevant limit, create the execution record, issue the scoped grant and append the authorization evidence. If one fails, none should be presented as committed.

That internal transaction ends before the external provider's independent system. A local database transaction cannot make a remote purchase atomic. The design therefore never promises exactly-once external execution. It combines:

• one-time authorization consumption;
• a stable request identity;
• provider-supported idempotency where available;
• stored request and response evidence;
• explicit uncertain-state handling;
• controlled reconciliation before a new attempt.

One Authorization, One Commit Boundary explains why this line matters and what evidence must cross it.

Uncertain Outcomes and Reconciliation

A timeout does not prove failure. The provider may have committed the transaction and lost the response. Automatically repeating a non-idempotent request can create a duplicate commitment. HTTP semantics similarly warns clients not to retry non-idempotent requests automatically unless they know the operation is effectively idempotent or the original was not applied.

The target lifecycle distinguishes:

• confirmed — provider evidence shows the authorized action committed;
• denied — policy or the provider refused it;
• failed — evidence shows it did not commit and the failure is definitive;
• uncertain — available evidence cannot establish whether it committed;
• reconciling — an authorized process is gathering provider evidence;
• reconciled — the final result is established and linked to the original request.

An uncertain result blocks blind retry. Reconciliation may confirm the original transaction, prove that no external effect occurred and allow a newly authorized attempt, or escalate for human review. The architecture does not turn “still unknown” into success or failure merely to simplify a dashboard.

“Uncertain” Is a State, Not an Error gives a concrete fault-handling checklist.

Evidence From Instruction to Outcome

An audit log is most useful when it explains causality rather than merely listing timestamps. The evidence chain should make these questions answerable:

• What did the human ask for?
• What exact transaction did the agent propose?
• Which policy version evaluated it, and why did it allow, deny or require approval?
• What did the human approve, or which delegation covered it?
• Which workload consumed the resulting grant?
• Which opaque provider reference and response were recorded?
• Was the first outcome definitive or uncertain?
• What evidence produced the reconciled result?

Integrity links can make later alteration visible, but “tamper-evident” is not “tamper-proof.” Independent retention, access control, key management, time sources, redaction and external verification remain deployment decisions outside this public architecture.

Performance Measurement Blueprint

There is no comparative benchmark for this work, so this release makes no comparative performance claim. A credible report should be added only after a reproducible measurement run records:

• source version and configuration;
• hardware and runtime environment;
• workload and dataset definition;
• warm-up behavior, sample count and concurrency;
• p50, p95 and p99 end-to-end latency;
• throughput under stated concurrency;
• error, denial, timeout and uncertain-outcome rates;
• authorization overhead by policy, approval, grant and broker stage;
• contention behavior at the authorization boundary;
• step-up and no-step-up paths;
• reconciliation duration and unresolved-case rate;
• test date and raw-result location.

The report should show distributions and tail behavior, not a single average. A result belongs on this page only when its method and evidence can be inspected. Until then, the measurement plan is a design output rather than an empty chart or synthetic number.

Evidence Boundary, Tradeoffs and Limitations

The reference design improves inspectability by adding explicit boundaries, but those boundaries cost time and complexity. Exact approval adds friction. Short-lived grants create renewal and clock-synchronization concerns. Credential brokers become sensitive infrastructure. Evidence retention creates privacy and minimization duties. Reconciliation adds operational work precisely when a provider is least clear.

The design also leaves important choices open:

• the identity and signing mechanisms used by a deployment;
• policy language, review process and emergency controls;
• credential storage and release implementation;
• isolation strength for the executor;
• provider-specific idempotency and evidence capabilities;
• evidence retention, redaction and independent anchoring;
• recovery from partial internal failures;
• jurisdiction-specific payment, procurement or compliance obligations.

These are not omissions to hide. They are the places where a conceptual architecture must be adapted, threat-modeled and validated before production use.

Applicable Domains

The same control pattern can govern procurement, travel, paid APIs and data, recurring operations, and cloud or service purchasing. The shared layer is not a universal action schema. Each domain still needs its own typed terms, risk policy, human presentation, provider adapter and reconciliation evidence.

A useful fit test is simple: if an agent action can create cost, liability, disclosure or a durable external change, it deserves an explicit authority and outcome boundary.

Procurement Preview

Illustrative Reference Project — not a deployed customer system.

The procurement example turns an employee request into structured requirements, supplier terms and a purchase proposal. Spend policy evaluates category, supplier status, amount, budget and delegation. Higher-risk proposals require exact approval. An isolated executor places the order, and acknowledgement plus receipt evidence closes or reconciles the transaction.

The practical half of the series develops that example without presenting it as a customer outcome:

• Where Secure Agent Transactions Fit: A Use-Case Map
• Building a Governed Procurement Agent
• Designing Spend Policies for Autonomous Buyers
• From Request to Receipt: A Procurement Transaction Walkthrough

Next Validation Steps

The next useful work is evidence, not stronger marketing language:

1. implement a bounded demonstration with synthetic providers and test identities;
2. publish threat scenarios and negative-path acceptance tests for all seven controls;
3. fault-inject timeouts before, during and after an external commit;
4. verify tenant, workload, audience, expiry and replay failures at every boundary;
5. produce a reproducible performance report using the measurement blueprint;
6. commission an independent security review before making assurance claims;
7. keep the public architecture conceptual even if the private implementation evolves.

The repository-access action on this page is intentionally separate from public source links. Requests are reviewed individually, and access is not guaranteed.