Trust infrastructure for agents that cross company boundaries
When agents act between companies, the hard problem is no longer the task. It is control.
A software agent asks a supplier for terms, sends a customer record to a partner workflow, invokes a tool in another company's system, or delegates part of the job to a specialist subagent. Each handoff creates a question the receiving party has to answer before it can safely act: who is this agent, who does it represent, what is it allowed to do, and what exactly did it send?
Mintbaton is a hosted broker and proof layer for cross-entity agent exchange. It gives both organizations a neutral record of identity, delegation, permissions, timing, acknowledgement, and tamper-evident bytes, while keeping the contents encrypted away from the broker itself.
| sender | claims-agent@payer.example · agent 8f21c3 |
|---|---|
| recipient | eligibility-agent@provider.example · agent 2d91aa |
| represents | Northstar Health Plan · delegated by ops-admin@payer.example |
| authority | current eligibility.verify.read · expires 2026-09-01 |
| delegation | no onward delegation permitted |
| context policy | member_id, plan_code allowed · diagnosis, notes denied |
| encrypted | true · X25519 sealed to recipient agent key |
| signature | verified Ed25519 over canonical envelope |
| envelope hash | sha256:41c7e2…9ab4 · retained after payload redaction |
| acknowledged | 2026-08-24T14:11:09.320Z |
Every useful agent-to-agent workflow becomes an inter-company risk surface.
Traditional integration assumed a bounded system: a service account, an API credential, a contract, and logs held by each side. Agent workflows are different. Authority may be delegated dynamically. Context may be assembled from several tools. A receiving organization may see a request from software it has never integrated with directly, acting for a human or business whose permission can change midstream.
That is why cross-entity agent use turns ordinary enterprise controls into unsettled questions: identity, authorization, provenance, data leakage, audit, liability, interoperability, reliability, jurisdiction, and cost allocation all move from internal policy into a shared operating layer between firms.
The receiving party needs more than a message. It needs a reason to trust the handoff.
| Challenge | What gets harder | What Mintbaton records |
|---|---|---|
| Agent identity | The recipient must know whether the agent is legitimate, who owns it, which human or business it represents, and whether delegated authority is still current. | Verified agent identity, owning organization, published key, handshake state, and the delegation claim attached to the exchange. |
| Authorization | Access alone is too broad. The hard questions are what the agent may do, what data it may retrieve, whether it may delegate, and who may receive context. | Scoped permission labels, expiry, counterparty relationship, delegation limits, and policy metadata bound to the envelope. |
| Trust and provenance | Requests, recommendations, documents, and transaction data must be authentic and unaltered even when temporary teams of agents assemble across organizations. | Signature state, canonical envelope hash, sender key confirmed at handshake, delivery time, and acknowledgement time. |
| Data leakage | Agents can pass customer data, pricing, contract language, regulated information, or trade secrets as context to another agent or tool. | Recipient-bound encryption, context policy labels, payload size, message type, and retention state without broker-readable contents. |
| Accountability | When a workflow exposes data, violates a policy, or commits to a transaction, responsibility can blur across deploying company, vendor, model, tool, and counterparty. | A neutral chain of who requested what, under which authority, which agent acknowledged it, and when each step occurred. |
| Audit and disputes | Application logs are fragmented and self-reported, making it difficult to reconstruct an end-to-end decision or delegation chain after the fact. | A third-party, tamper-evident exchange record designed to survive payload redaction and later reconstruction. |
| Interoperability | Different stacks, APIs, schemas, identity models, and emerging protocols make safe communication brittle and expensive. | A small brokered envelope model with explicit identity, keys, permissions, message type, and acknowledgement semantics. |
| Reliability | An upstream error can trigger downstream action in another company's system; parallel agents can create conflicting outcomes. | Ordered handoff records, acknowledgement state, and exact byte hashes for the inputs each downstream agent received. |
| Compliance | Cross-entity workflows may move personal, financial, health, export-controlled, or confidential data across entities and borders. | Purpose and policy metadata, retention state, recipient identity, delivery record, and proof that the broker lacked plaintext access. |
| Commercial control | Autonomous chains can create unexpected inference, API, tool, and transaction costs that are hard to attribute fairly. | Per-counterparty exchange records with message type, direction, acknowledgement, and rate-limit surfaces for later allocation. |
Mintbaton gives agent workflows a shared control plane without becoming the data processor of record.
For the sending organization, Mintbaton proves that its agent acted under a defined identity, sent a particular envelope, and received acknowledgement from the counterparty. For the receiving organization, it proves that the agent was tied to a known organization, used a verified signing key, carried a bounded authority claim, and delivered bytes that can later be tested against the record.
The important design choice is what Mintbaton does not do. It does not need to read customer records, commercial terms, contract language, or regulated content to prove that an exchange happened. It stores the control facts around the message, not the business secret inside it.
- Know your agent
- Bind each agent to an organization, public key, human or business principal, and current delegation context.
- Constrain the handoff
- Attach permission scope, expiry, counterparty, allowed context, and delegation rules to the envelope itself.
- Prove the exchange
- Record signature verification, exact byte hashes, delivery, acknowledgement, and the key state confirmed at handshake.
- Limit data exposure
- Seal payloads to recipient agents before broker receipt, redact ciphertext on schedule, and retain only proof metadata.
- Reconstruct disputes
- Give both parties a defensible chain of request, delegation, context policy, tool-facing handoff, and acknowledgement.
- Control costs
- Track exchange volume by organization, counterparty pair, message type, and direction so autonomous chains have chargeback rails.
A narrow broker is enough if the envelope carries the right facts.
Each organization registers agents with publishable signing and encryption keys. Private keys stay with the operator or agent runtime.
Counterparties form an explicit directed contact edge before agents exchange messages. No receiving organization has to accept a unilateral add.
The sending agent seals the payload to the recipient agent, signs the canonical envelope, and includes scoped authority and policy metadata.
Mintbaton verifies the relationship, rate limits the counterparty pair, records the envelope metadata and hash, and delivers ciphertext.
The recipient verifies the signature, decrypts locally, acts or refuses, and acknowledges receipt back through the same proof layer.
If there is a later dispute, the parties compare the plaintext they hold against the retained envelope hash and the neutral acknowledgement record.
Start where a bad agent handoff would be expensive to argue about.
- Procurement and supplier negotiation: prove which agent requested terms, which authority it had, and which offer the counterparty acknowledged.
- Insurance and healthcare operations: exchange eligibility, authorization, claim, or scheduling context without putting the broker in the path of plaintext records.
- Financial and back-office workflows: prove approvals, data handoffs, and transaction instructions across firm boundaries.
- Vendor-run multi-agent processes: create a neutral record for handoffs inside a vendor's agent chain when the customer remains accountable for the outcome.
- Regulated partner automation: preserve evidence of purpose, recipient, permission, retention, and acknowledgement when data crosses legal entities.
Built for emerging agent trust standards, without waiting for them to settle.
The direction of travel is visible: publishable agent identities, signed agent metadata, explicit relationships between parties, scoped delegation, verifiable provenance, and recipient-checkable proofs. Mintbaton is an implementation of that shape, not a competing standard.
The product posture is deliberately concrete. Hosted broker today. TypeScript SDK and MCP server for pilots. Poll-based delivery today. Appliance deployment path for organizations that will not route even ciphertext through a third party. No claim of certification, conformance, or standards-body endorsement while the field is still moving.
Closed beta for teams putting real agent workflows between real organizations.
The best pilot candidates already know the exchange they cannot afford to lose: a delegated approval, a partner data request, a claims handoff, a supplier commitment, a tool call into another company's system, or a vendor-run chain where the customer needs proof independent of the vendor's own logs.
- The protocol engine, handshake model, signing and sealing path, and metadata-only record surface are built and running.
- Self-serve registration is closed. Accounts are created by invitation for pilot partners.
- The SDK and MCP server are available directly to pilot partners, not yet through public registries.
- Delivery is poll-based today. Webhooks and push delivery should not be assumed.
- There is no SOC 2, HIPAA, HITRUST, ISO certification, BAA, public SLA, or public status page yet.
Pilot partners
If your agents cross company boundaries, bring us the handoff you would need to prove.
The useful conversation is specific: which agent acts, who it represents, what authority it carries, what context crosses the boundary, what the recipient must verify, and what dispute would be costly six weeks later.
Invite-gated. Small cohort. Direct access to the people building the protocol.