Enterprise AI Agents: Secure Transactions With One Company

12 minute read

Enterprise AI agents do not need every counterparty to adopt the same trust protocol before transactions become safer. Cross-enterprise standards often begin with the end state: compatible identities, portable authority, a shared transaction format and signatures from both companies.

That can produce strong evidence, but it is a poor starting condition for adoption. An API provider cannot wait for every customer agent to install a new trust stack. A buying enterprise cannot require each supplier to understand its agent protocol before automating a purchase. Most real integrations begin with an OAuth token, API key, JWT subject or existing service account.

One participating company can still improve control. It can map the existing credential to a local agent identity, require bounded authority, enforce deterministic policy and sign a receipt for what it observed. The counterparty keeps using its current API and credentials.

The result is useful, but its assurance has a limit. The receipt is unilateral evidence. Its signature proves what the deploying company attested about its observation and controls. The receipt does not prove that every path passed through enforcement, or that the other party agreed with the transaction.

Teams can start with ordinary API access and add stronger bilateral evidence when the counterparty is ready.

Place enterprise AI agent control on the side that needs it

There are two useful deployment modes.

In inbound trust, an API, data or SaaS provider places an enforcement gateway in front of its existing service. Customer agents continue to send ordinary authenticated requests. The provider uses the gateway to control tenant access, allowed operations, sensitive fields, usage and evidence.

In outbound control, an enterprise places a gateway between its own agents and an unchanged supplier, SaaS platform, managed-service provider or payment API. The external system receives the same request and credential format it already supports. The enterprise uses the gateway to constrain destinations, amounts, tools and purposes before traffic leaves its environment.

Inbound trust

External agent -> existing credential -> provider gateway -> existing API

Outbound control

Enterprise agent -> enterprise gateway -> existing credential -> external API

Both patterns rely on the same transaction core. The deployment location and accountable operator differ.

Consider an inbound B2B SaaS case. A customer has an automation agent that can read account data and issue refunds through the provider's existing OAuth API. The provider wants to limit autonomous refunds to a specific tenant and amount, route larger refunds for approval and prove which controls ran.

The customer does not need to know about the new enforcement system. It keeps presenting the OAuth token it already has.

Map an existing credential to local agent context

The gateway first authenticates the request using the current mechanism. It then resolves the credential to a local record that names the customer organisation, agent or workload, tenant, assurance level and status.

credentialMapping:
  issuer: https://identity.customer.example
  subject: 7dbb19f4-2f7a-4f72-a9da-2d65fa4bd915
  audience: https://api.vendor.example
  localOrganisation: org:vendor:customer-418
  localAgent: agent:vendor:customer-418:refund-worker
  tenant: tenant-418
  assurance: credential-mapped
  status: active

Credential mapping is not the same as portable agent identity. The provider knows that a verified credential maps to a local record under its own governance. It has not received a Passport signed by the customer's organisation.

That distinction matters in user interfaces, policy and receipts. Call the assurance level credential-mapped, or another equally explicit term. Do not label the agent "verified by Customer A" unless Customer A supplied evidence that supports the claim.

Mapping records need lifecycle controls. Track who created the mapping, the authoritative credential attributes, tenant binding, allowed audiences, status, effective dates and revocation source. Reject caller-selected organisation or tenant headers unless a verified identity claim authorises them.

Add local authority without changing the remote protocol

The provider can issue or require a local mandate for the mapped agent. That mandate expresses what the provider accepts from this identity. It does not claim that the customer's board or legal representative delegated the authority unless the provider has verified such evidence.

For the refund example:

{
  "mandateId": "mandate_refunds_tenant_418",
  "subject": "agent:vendor:customer-418:refund-worker",
  "issuer": "org:vendor",
  "purpose": "customer-support-refund",
  "validFrom": "2026-08-10T00:00:00Z",
  "expiresAt": "2026-08-17T00:00:00Z",
  "constraints": {
    "actions": ["refund.create", "refund.status.read"],
    "tenantIds": ["tenant-418"],
    "currencies": ["EUR"],
    "maxAmountMinor": 10000,
    "maxDailyTotalMinor": 50000,
    "destinations": ["original-payment-method"],
    "delegation": { "allowed": false }
  }
}

The mandate is useful because OAuth scopes such as refunds:write are usually too broad for transaction controls. A scope can say that the client may call a refund endpoint. A mandate can also limit tenant, amount, currency, destination, purpose, cumulative use and expiry.

Keep the authority statement honest. In a one-participant inbound deployment, the provider is enforcing its own accepted limits on a mapped customer credential. A later integration may allow the customer to present a signed mandate from its own issuer. That gives the provider stronger evidence about customer-side delegation, subject to trust and verification policy.

Normalise every request into a transaction envelope

Legacy APIs express context in different places. The tenant may appear in the URL, the refund amount in JSON, the OAuth subject in a token and the purpose in a ticket field. The gateway should extract those values into one canonical envelope before policy evaluation.

type NormalisedTransaction = {
  transaction: Transaction
  canonicalDigest: string
}

function normaliseRefund(
  req: HttpRequest,
  identity: Identity
): NormalisedTransaction {
  const transaction: Transaction = {
    id: requireIdempotencyKey(req),
    agent: identity.localAgent,
    organisation: identity.localOrganisation,
    tenant: identity.tenant,
    assurance: identity.assurance,
    action: "refund.create",
    resource: `tenant/${req.params.tenantId}/charge/${req.body.chargeId}`,
    counterparty: req.body.merchantAccount,
    destination: "original-payment-method",
    purpose: req.body.reasonCode,
    amount: {
      minor: req.body.amountMinor,
      currency: req.body.currency,
    },
    requestedAt: req.receivedAt,
  }

  return {
    transaction,
    canonicalDigest: sha256(canonicalise(transaction)),
  }
}

Schema validation should happen before the transaction reaches a policy engine. Reject unknown currency formats, ambiguous amount units and duplicate identifiers. Canonicalisation should produce a stable digest used by policy, approval, execution and the receipt.

Do not let the connector contain unique business policy. Its job is to translate between the existing API and the transaction model, then translate an authorised transaction back into the upstream request. Keeping policy outside the adapter makes it testable and reusable.

Evaluate local policy and authority together

The gateway verifies the credential mapping and mandate, then evaluates the envelope against current business policy. The decision should be deterministic and versioned.

deny if mapping.status != "active"
deny if mapping.tenant != transaction.tenant
deny if transaction.action not in mandate.constraints.actions
deny if transaction.tenant not in mandate.constraints.tenantIds
deny if transaction.amount.currency not in mandate.constraints.currencies
deny if transaction.amount.minor > mandate.constraints.maxAmountMinor
deny if dailyConsumedMinor + transaction.amount.minor > mandate.constraints.maxDailyTotalMinor
deny if transaction.destination != "original-payment-method"

approval_required if account.riskHold == true
approval_required if transaction.purpose == "exception"

deny if idempotency.reserve(transaction.id, transactionDigest) fails

allow otherwise

An approval result does not consume the idempotency reservation in this sketch. The caller later resubmits the same transaction digest with a bound approval, and the gateway reserves execution immediately before dispatch. A production state machine needs explicit pending_approval, reserved, executing and terminal states so abandoned approvals and retries cannot strand the key.

Run this policy near the protected service. The data plane should not depend on a SaaS round trip for every decision. Distribute signed policy bundles and cache trust state with clear freshness limits. Material writes should fail closed when required trust, revocation or replay state is unavailable. If a team permits fail-open behavior for low-risk reads, configure it separately and explicitly.

Input and output controls belong in the same path. The gateway can remove fields the agent is not allowed to send, restrict a query to the mapped tenant and filter sensitive response fields. Record the transformation digest so the evidence describes the request that actually reached the service.

Preserve the existing API contract

The non-participating party should see ordinary protocol behavior.

For an inbound deployment, the customer agent receives the API's normal success response, a structured denial or a pending state if approval is required. The provider may expose a receipt reference as an optional response header without requiring the customer to process it.

For an outbound deployment, the supplier receives the same OAuth token or API request it already expects. The enterprise gateway can broker the credential, enforce the local decision and store the receipt internally. The supplier does not need an OATI account, SDK, Passport or signature.

This constraint prevents architecture drift. If every connector asks the remote system to adopt a new object model before it can run, the design has stopped being one-participant.

Sign evidence with the right assurance label

After execution, the participating company's enforcement system can issue a signed receipt containing:

• the locally resolved organisation and agent;
• the credential-mapping assurance level;
• the mandate and policy references;
• the canonical request digest;
• the decision and any approval;
• the executed request and response digests;
• the external service reference;
• timestamps, nonce and idempotency data;
• issuer and signature metadata.

The receipt can support internal audit, billing reconciliation and incident investigation. An independent verifier can check the signature and referenced objects without trusting the dashboard that displays them.

It cannot establish facts the signer did not observe. In the outbound case, a receipt may prove that the enterprise sent a request and recorded a supplier response. It does not prove that the supplier fulfilled the order. In the inbound case, it may prove what the provider released. It does not prove that the customer intended the request unless the customer's own trustworthy mandate or signature supports that conclusion.

Use progressive assurance labels:

Each level adds evidence. None should retroactively inflate the meaning of an earlier receipt.

Four practical deployment patterns

Paid data API

The provider maps an existing customer API key to an agent record. A local mandate limits datasets, query types, volume, purpose and retention terms. The gateway filters released fields, meters usage and signs a receipt for what it returned. The customer continues using the existing endpoint.

Procurement agent

The buying enterprise places an outbound gateway before supplier APIs. It checks the approved supplier, product, quantity, amount, currency, purpose and delivery destination. After approval, it calls the supplier using the existing credential. Its receipt is evidence of the buyer-side decision and observed response, not supplier agreement.

External remediation agent

An enterprise maps an MSP agent's existing service credential to a local identity. A mandate restricts tools, production resources, ticket numbers and maintenance windows. The gateway brokers a temporary upstream credential and records the executed change. The MSP does not need to run the same trust system.

Insurance information exchange

An insurer maps a broker's existing OAuth client to a local agent and claim context. Policy limits the documents, fields, purpose and release destination. A unilateral receipt records what the insurer released under its controls. It does not prove how the broker later used the data.

Failure cases that matter

Credential mapping becomes a shadow identity system

Mappings accumulate, owners leave and customer tenants change. Treat mappings as governed records with expiry, review, revocation and authoritative source binding. Never infer legal ownership from a friendly display name.

The gateway trusts caller-supplied context

An agent sends X-Tenant-ID: tenant-7 while its credential belongs to tenant-418. Derive tenant and organisation from verified identity, then compare them with request context. Do not let headers choose the security principal.

A connector hides policy

One supplier adapter silently accepts a higher amount because the upstream API uses decimals. Canonicalise amounts into explicit units before evaluation. Keep provider-specific translation separate from provider-neutral policy.

The receipt implies counterparty agreement

The UI labels a local receipt "verified transaction" without stating who signed it. Display issuer, assurance level and countersignature status. A unilateral receipt is useful precisely when its limits are clear.

The remote call times out

Do not record failure and retry blindly. Mark the execution result unknown, reconcile through the remote operation reference or idempotency key, then append the resolved state. The original evidence should remain immutable.

Traffic bypasses enforcement

If an agent can still reach the API directly, policy is optional. Use network routes, service mesh policy, egress controls or API configuration to make the gateway the only accepted path for the protected operation.

Implementation checklist

• Pick inbound or outbound enforcement based on who needs control now.
• Authenticate with the existing credential before mapping local context.
• Bind mappings to issuer, subject, audience, tenant, status and lifecycle.
• Label credential-mapped identity separately from portable identity.
• Express local authority with short expiry and machine-checkable constraints.
• Normalise API and MCP calls into a canonical transaction envelope.
• Keep connector translation separate from business policy.
• Evaluate identity, mandate, transaction and business policy together.
• Enforce replay protection and idempotency before writes.
• Keep policy and required trust state available near the data plane.
• Make bypass technically difficult through network and service controls.
• Sign receipts with issuer and assurance level visible.
• Treat unilateral evidence as unilateral.
• Add Passport, Mandate exchange and countersigning only when counterparties are ready.

Related engineering guides

• Use bounded delegation in multi-agent systems inside the participating enterprise.
• Learn what unilateral evidence can support in AI agent observability: receipts versus logs.

An incremental OATI path

OATI's first one-participant assurance level can begin with an existing credential mapped to a local agent record. A Passport is optional at this stage. The participating company then applies local authority and policy and issues a unilateral Action Receipt. Presenting a Passport, a counterparty-issued Mandate or a countersignature raises the assurance level when those objects become available. The public developer framework implements core records, signing, verification, deterministic evaluation, lookup and reference middleware. A deployed trust and lookup slice exists, but the project remains a developer preview pending independent review and further production acceptance work.

The full commercial gateway fleet, business approval workflows, durable bilateral evidence and federation are target-state capabilities. Developers do not need to wait for that end state to use the pattern. Start by making one company's enforcement better, say exactly what the resulting evidence proves, and leave the remote API alone.