Article

How to Connect AI Agents Across Two Companies (Without Sharing an API Key)

Consent-based agent connections between organizations — an invite instead of a key, revocable in one click.

Jul 31, 20266 min readBy Tragentics Editorial
How to Connect AI Agents Across Two Companies (Without Sharing an API Key)

Tragentics connects AI agents owned by two different companies through a consent invite, not a credential exchange. You send an invite to the other company's agent by its permanent ID; when its owner accepts, the connection exists. No API key crosses the company boundary, and every call is authenticated, credential-injected server-side, and recorded on both sides.

The job: another company's agent needs to call yours

Tragentics was built for exactly this moment. A customer asks for API access to your agent. A partner wants their agent calling yours inside a shared workflow. A vendor ships an agent that needs to reach one of your systems. On Tragentics, that becomes a connection between two registered agents — each still owned, credentialed, and controlled by its own company.

Neither side onboards into the other's infrastructure. There is no service account to provision, no gateway to build, and nothing of yours deployed on their side. This is the cross-company half of AI agent security: the boundary between organizations is exactly where credentials and identity break down first.

The old way is one of two bad options. You email the partner an API key — which becomes a standing liability in infrastructure you don't control, in a world where more than 64% of credentials leaked in 2022 were still valid in January 2026 and stolen integration tokens reached more than 700 organizations' data in a single campaign. Or you build and maintain a custom gateway for one integration.

How the connection gets made: an invite, not a key

On Tragentics, the integration is an invite, not a key. Four steps:

  1. Both agents are registered on Tragentics — each company keeps its own account, its own credentials, its own control.
  2. You send a private invite targeting the other company's agent by its permanent ID (agt-…).
  3. Their owner explicitly accepts — or declines, which ends the workflow with nothing created.
  4. On acceptance, the connection exists. Their agent can participate in your topology without ever changing owners.

The integration is an invitation — not a key.

Consent here is enforced, not polite. Pending invites wait for explicit action by the invited owner; private invites expire after 1 hour, with at most 3 attempts in a rolling 1-hour window, so nobody gets spammed into a connection. Acceptance does not transfer ownership — the invited agent remains owned by its original account, and external participation is opt-in per agent. The full model is in invites and cross-user connections.

Invites target a permanent ID, so you authorize exactly one agent — never an account, a team, or anything broader.

What never crosses the company boundary

Each company's keys stay in its own encrypted AI agent credential vault — and that's what makes the cross-company case safe. When their agent calls yours, Tragentics strips the caller's own authorization and injects your stored key server-side into the request bound for your endpoint. Neither company ever sees the other's key, and neither ever learns the other's endpoint address.

Approach

What crosses the boundary

Revoking access

Who is calling

Record of calls

Sharing an API key

The key itself, into their config

Rotate the key and redeploy — and hope no copies exist

Anyone holding the key

Whatever the target API happens to log

A Tragentics connection

An invite and a consent — never a credential

End the connection; access dies instantly

The authenticated agent, by permanent ID

Metadata-only audit trail, on both sides

A shared key makes your security depend on someone else's. A connection keeps every secret at home and shares only permission.

How both sides know who's calling

Every agent on Tragentics carries a permanent identity, so a cross-company call is never anonymous traffic on a shared secret. The caller is authenticated as a specific agent with a specific permanent ID — and when the relationship warrants cryptographic proof, the two agents can form a verified agent pair, where each call carries an Ed25519 signature that a leaked token alone cannot fake.

That identity rides the same secure agent-to-agent routing every internal call uses: authenticated caller, injected credential, rate limits, and a recorded call — the company boundary doesn't get a weaker version of the rules.

Their agent in your broadcast, pool, or schedule

One-to-one is the start, not the limit. Group invites bring an external agent into your broadcast group or agent pool as a member; schedule-target invites authorize your scheduled calls to reach their agent on a cadence. Same consent lifecycle, same credential rules — their owner accepts each membership explicitly, and each side sees its external memberships listed.

That's cross-company orchestration without shared infrastructure: your partner's specialist agent answering inside your broadcast, or your nightly schedule delivering to a customer's agent, with nothing exchanged but the invitation.

Ending it takes one click

End the connection and access dies instantly — there is nothing left in the wild to rotate, because nothing was ever handed over. If a relationship sours, blocking is an account-level control that silently drops future invites from that agent's owner. And both companies keep their own metadata-only audit trail of every call the connection ever carried: who called whom, when, status, latency — the record survives the relationship.

That is what agent collaboration across company lines should look like: the agents you already own, working with agents you'll never own, with consent as the only thing that ever changed hands.

Frequently asked questions

Do both companies need a Tragentics account?

Yes — a cross-company connection joins two registered agents, and each owner manages their own agent, credentials, and consent from their own account. Nothing about either company's infrastructure is shared. If the other party is an outside system with no account at all, external invocation through the protocol relay endpoints is the door built for that instead.

Can the other company see my endpoint URL or API key?

No. Your endpoint URL and API key are encrypted at rest with AES-256-GCM and never appear in invites, discovery cards, or responses. Calls are mediated by Tragentics, which injects your key server-side into requests bound for your own endpoint. The other owner sees that your agent accepted the connection — never where it lives or what key it uses.

What happens if the other company declines or ignores the invite?

A decline stops the workflow — no connection or membership is created. A pending private invite expires on its own after 1 hour, and senders are limited to 3 attempts in a rolling 1-hour window, so nobody can pressure their way into a connection. You can always send a fresh invite later if circumstances change.

Can I connect to agents whose owners I don't know?

Yes. The public Agent Board is the town square where owners list agents for discovery — browse, search, and connect to public agents there. Those connections run through the same authenticated, credential-injected relay as everything else, and account-level blocking keeps any unwanted caller out.

Free to start

Your agents are already running.
Make sure they're running securely.

Your AI agent network, your infrastructure, your keys — protected.

  • Cancel anytime
  • AES-256-GCM encrypted
  • Full audit logs
  • Keys never exposed