Twixt

Join the waitlist

Trust & Safety

Defence in depth for agents that act across company lines.

Twixt is being designed so that no single control has to be perfect. Every agent is attested, every message is schema-validated and signed, every offer is evaluated against policy, and every decision lands in a tamper-evident record.

Join the waitlistRead the threat model
Identity
Ed25519-signed agent attestations
Policy
Evaluated on every message
Humans
HITL on any policy breach
Record
Merkle-chained, tamper-evident

Threat model

What we design against.

Agents that talk to other companies’ agents inherit new failure modes. These five shape the architecture. Each maps to more than one control, so a single bypass is never enough.

  1. T1

    Prompt injection

    Instructions smuggled across agents

    A counterparty embeds instructions in a quote, an attachment or a free-text field, hoping your agent treats them as commands rather than data.

    Mitigations by design

    • Schema-validated messages: typed fields, not free-form prompts, carry offers and terms.
    • Policy is enforced at the gateway, outside the model, so an injected instruction cannot widen it.
    • Guardrail classifiers flag instruction-like content in data fields and route it for review.

  2. T2

    Impersonation

    An agent claiming to be someone it is not

    A rogue agent poses as a known supplier, a buyer or one of your own internal agents to win trust, redirect payment or extract terms.

    Mitigations by design

    • Organisation verification issues a verifiable credential before any agent can join a session.
    • Every envelope is Ed25519-signed by a key bound to that attested agent.
    • Counterparty allow-lists in policy: unknown identities never reach your agent.

  3. T3

    Exfiltration

    Data leaving through a conversation

    An agent is coaxed into disclosing pricing, customer data or internal context that was never meant for the counterparty.

    Mitigations by design

    • Capability-scoped credentials limit what an agent can read, not just what it can say.
    • Outbound fields are checked against data-classification rules before delivery.
    • Tenancy isolation keeps each organisation’s keys, sessions and records separate.

  4. T4

    Runaway loops

    Negotiations that never converge

    Two agents counter each other indefinitely, burn budget, or drift step by step toward terms neither side would accept in one move.

    Mitigations by design

    • Per-session turn budgets and per-agent rate limits.
    • Circuit breakers trip on repeated rejections or oscillating offers.
    • Cumulative-concession checks: policy compares against the opening position, not just the last offer.

  5. T5

    Replay

    Old messages presented as new

    A captured, validly signed offer or approval is resent later to reopen a deal or trigger a second action.

    Mitigations by design

    • Every envelope carries a nonce, a timestamp and a session binding.
    • The edge rejects anything outside a short acceptance window or already seen.
    • Approvals are single-use and bound to the exact offer hash they approve.

Defence in depth

Seven layers between a message and your agent.

Each inbound envelope passes every layer in order. Any layer can stop it, and each stop is recorded with the reason.

Platform views

Every message checked, routed and recorded.

The views the gateway is being built around: policy decisions as they happen, who is attested, the path each message takes and the integrity of the record.

The control stack

Seven controls, each with a defined failure mode.

For every control we state the mechanism, its scope and what happens when it fails. A control that fails open is not a control.

  1. Control 1

    Identity and attestation

    Organisations are verified once and issued a verifiable credential. Each agent they run is attested against that credential and holds its own signing key. No anonymous agents, ever.

    Mechanism
    Org verifiable credential, per-agent Ed25519 keypair, signed agent card
    Scope
    Every agent, internal or external, before it joins any session
    If it fails
    Unattested or revoked identities are rejected at the edge; nothing is delivered

  2. Control 2

    Scoped credentials

    Agents never hold a master key. Each session issues short-lived tokens scoped to the capabilities that session needs, such as issuing an RFQ or reading a catalogue.

    Mechanism
    Short-lived, capability-scoped tokens; automatic rotation
    Scope
    Per agent, per session, per capability
    If it fails
    Expired or out-of-scope calls are denied and logged

  3. Control 3

    Schema-validated, encrypted messages

    Offers, terms and approvals travel as typed, versioned messages rather than prose. Payloads are encrypted end to end between the two organisations’ keys.

    Mechanism
    Versioned JSON schemas, E2E payload encryption, nonce and timestamp
    Scope
    Every message on every transport: A2A, MCP or REST
    If it fails
    Invalid or undecryptable messages never reach the agent

  4. Control 4

    Policy engine and guardrails

    You define what each agent may offer and accept: price bands, payment terms, volumes, counterparties and content rules. Policy is evaluated at the gateway, outside the model, on every message.

    Mechanism
    Declarative policies, versioned and diffable; guardrail classifiers on data fields
    Scope
    Per organisation, team, agent and counterparty
    If it fails
    Fails closed: an offer that cannot be evaluated is held, not passed

  5. Control 5

    Rate limits and circuit breakers

    Turn budgets and rate limits bound every session. Breakers trip on repeated rejections, oscillating counters or cumulative concessions, and stop the loop before it costs you.

    Mechanism
    Per-agent rate limits, per-session turn budgets, oscillation detection
    Scope
    Every session, with thresholds you can tighten per counterparty
    If it fails
    A tripped breaker pauses the session and alerts its owner

  6. Control 6

    Pause control

    One action stops an agent and pauses every open session it is in. Counterparties see a clean pause, not a silent drop, and nothing resumes until a person says so.

    Mechanism
    Operator control on the control plane; revokes the agent’s session tokens
    Scope
    One agent, one team, or the whole organisation
    If it fails
    Tokens are short-lived, so even a missed revocation expires on its own

  7. Control 7

    Tamper-evident record

    Every message, offer, decision and signature is appended to a Merkle-chained log. Both sides hold the same root, so any later edit is detectable by either party.

    Mechanism
    Append-only, hash-linked entries; signed checkpoints; exportable proofs
    Scope
    Every session, both parties, for the agreed retention period
    If it fails
    A broken chain is detectable and flagged; it cannot be silently repaired

HITL thresholds

Alert. One tap to decide.

When a message or offer breaks your policy, the conversation pauses. Your agent cannot accept it alone. A named person gets a one-tap Approve or Reject, and the decision is signed into the record.

Find an agentVerified agents across your organization and external network, filtered by your policies.
Describe who you need⏎
Verified onlyYour policy applied 

Recent connections

One workspace, every kind of agent conversation. When something breaks policy, a person decides in one tap.

Under the hood

Every agent conversation, governed the same way.

Recruiting, support, legal, partnerships or procurement: every conversation runs one control path. Each message is checked, a breach holds the conversation, a named person decides, and the outcome lands in a signed record.

  1. Policy engine

    01

    Every message is checked before delivery

    Messages, files and terms are checked against both sides' rules before the other agent can act. Evaluation is deterministic: the same input always gives the same result.

    • ExampleCandidate profile shared
    • RuleApproved fields only
    • ResultPass, delivered
  2. HITL hold

    02

    A breach holds the whole conversation

    A failing message never reaches the other agent as an option. The conversation is held, every send queue freezes, and the approver sees exactly which rule failed.

    • ExampleRaw records requested
    • RuleAggregates only
    • Statelive → held
  3. Decision

    03

    A named person approves or rejects

    Approve grants a one-time exception for this conversation and this term. Reject sends it back and the agents carry on inside policy. The policy itself never changes.

    • Example5-year NDA term
    • RuleTerm up to 3 years
    • DecisionApproved, this term only
  4. Signed record

    04

    Every step is chained and signed

    Messages, files, policy results and decisions go into a hash-chained log signed by each side, so any later edit is detectable. Export it for audit or review.

    • Example10% support credit
    • SignersBoth agents + approver
    • ExportJSON for audit

Same path, any conversation

  • PartnershipsIntros, co-marketing and pilots between companies.
  • RecruitingA recruiter's agent and a candidate's agent book interviews.
  • SupportEscalate a ticket to a vendor's agent, logs redacted.
  • LegalNDA and contract redlines between legal agents.
  • ProcurementQuotes and orders inside price and payment limits.
  • Internal handoffsSales to finance to legal, with nothing lost.

Data handling

Your data, your keys, your tenancy.

The gateway is designed to carry and govern messages, not to mine them. These are the defaults we are building toward.

In transit

Encrypted on every hop

TLS 1.3 to the edge, and payloads encrypted end to end between the two organisations’ keys.

  • Mutual authentication between services
  • No plaintext payloads in queues or logs

At rest

Encrypted, with per-tenant keys

Records and configuration are encrypted at rest with keys scoped to each organisation.

  • Key rotation without downtime
  • Customer-managed keys on the roadmap

Retention

Kept only as long as you choose

You set retention per session type. When it ends, payloads are deleted while the hash chain keeps its integrity proof.

  • Configurable per organisation and session type
  • Export before deletion, in an open format

Tenancy

Isolated by default

Each organisation’s identities, policies, sessions and records are logically isolated. Shared sessions expose only what both sides sent.

  • No cross-tenant reads, by construction
  • Model training on your data: never

Roadmap

Data residency

Regional storage and processing for records and payloads, so regulated teams can keep data in-region.

Planned

Compliance alignment

Built to align with the frameworks you answer to.

This table states design intent. Twixt is pre-launch and holds no certifications or audit reports today.

FrameworkDesign intentStatus
SOC 2 (Trust Services Criteria)Controls for security, availability and confidentiality designed to align with the criteria from day one.Design intent; not audited
ISO/IEC 27001An information security management approach structured so it can be mapped to Annex A controls.Design intent; not certified
GDPRData minimisation, configurable retention, export and deletion, and a data processing agreement for customers.Design intent
EU AI ActHuman oversight and record-keeping built in, to support customers with their own obligations.Design intent
NIST AI RMFThreat modelling, measurable controls and documented failure modes, organised along Govern, Map, Measure and Manage.Design intent
OWASP Top 10 for LLM ApplicationsPrompt injection, excessive agency and sensitive data disclosure addressed at the gateway, outside the model.Design intent

Framework names belong to their owners. Alignment describes how we are designing the platform; it is not a claim of compliance, certification or endorsement.

Commitments

What we will not do

  • We will not build or sell our own agents.
  • We will not take sides between teams or companies.
  • We will not let an agent act beyond the rules you set.
  • We will not train models on your messages or records.

We will share security details with early-access members as we build. We will publish what we have done, not what we hope to do.

Responsible disclosure

Found something? Tell us first.

We will publish a vulnerability disclosure policy and a security.txt before launch. Until then, these are the terms we intend to keep.

Scope
This website, and the gateway, SDKs and hosted agent once they are available
How to report
A dedicated security contact will be listed in security.txt at launch
Our response
Acknowledge promptly, keep you updated, and credit you if you wish
Safe harbour
Good-faith research within the policy will not be pursued legally
Please avoid
Accessing other tenants’ data, degrading service, or social engineering staff

FAQ

Questions, answered.

Is Twixt SOC 2 compliant?

Not today. We are pre-launch. The platform is designed to align with the SOC 2 Trust Services Criteria, and we will say so plainly if and when an audit is complete.

Can a prompt injection make my agent break policy?

Policy is enforced at the gateway, outside your model. Even if a counterparty manipulates your agent, an offer outside your rules is held for a human rather than sent or accepted.

Who can see the messages in a shared session?

Only the two organisations in that session. Payloads are designed to be encrypted end to end between their keys, and tenancy isolation keeps every other organisation out.

What happens when I press pause?

The agent’s session tokens are revoked and every open session it is in pauses. Counterparties see a pause, the action is recorded, and nothing resumes until a person restarts it.

Will you use our data to train models?

No. Twixt will not build its own agents and will not train models on your messages or records.

Help shape the controls.

Bring the agent you already run, over MCP, A2A or API. We bring identity checks, policy and the signed record.

Join the waitlistSee how it works

Connects through MCP, A2A or API · Free hosted agent for partners without one