There's a conversation happening at every B2B company that's seen any AI adoption, and it goes roughly like this:

Partner: "Our agent needs to query your data to do its job for our shared customer. Can you give us API access?" Your sales team: "Yes, of course." Your security team: "Absolutely not." Your engineering team: "We could give them an API key with limited scope?" Your security team: "An API key that does what? Lives where? Gets rotated when? Audited how?"

Every company we talk to has this conversation. Most of them end it the same way: by punting. Either the integration doesn't happen, or it happens through a one-off arrangement that doesn't scale, or it happens through a shared API key that everyone privately knows is a problem they'll deal with later.

The pattern is solvable. It's just been solved one company at a time, badly, when it should be a platform feature.

Why the easy answers don't work

API keys. A shared secret given to a partner is a shared secret given to whoever in the partner's organization can read their config files, their CI logs, their developer laptops. The blast radius of a leak is huge, and you can't tell when it leaks. Not a good fit for partner integrations at scale.

OAuth on the partner's behalf. Better, but designed for human users. Adapting it to agents requires shoehorning. The token scopes weren't designed with agentic workloads in mind. Refresh flows assume a human is around to re-authenticate periodically.

Custom integration per partner. This is what most companies actually do. It works, sort of, until you have ten partners and each integration looks slightly different and your support burden is proportional to the number of partners you've onboarded. Doesn't scale.

What's actually needed is a way for an external agent to:

  • Prove its identity cryptographically, using keys the partner controls — not shared secrets they had to copy from a Slack message.
  • Be assigned a scoped credential that limits it to specific operations on specific resources.
  • Be revoked unilaterally by you, without asking the partner.
  • Leave a clean audit trail you can show your security team.
  • Onboard through a documented, repeatable process — not a one-off email thread.

This is what we built.

What we built

Helix lets a partner bring their own agent into your environment with the security model of a real service-to-service integration, not a shared-secret hack:

  • External agents authenticate using infrastructure your partner already controls. No shared secrets, no Slack-DM'd API keys, no "rotate this every 90 days and pray." The partner's agent proves who it is using credentials the partner manages on their side; you don't hold them.
  • You grant time-bounded, scoped access on top of that identity. Specific datasets, specific operations, an end date. Nothing implicit, nothing inherited, nothing that quietly survives the contract.
  • Revocation is unilateral and instant on your side. You can pull access without coordinating with the partner — useful in incidents, contract endings, or routine cleanup. They don't have to cooperate, and the action takes effect right away.
  • Every interaction is audited. The partner's agent appears in your trail with its identity, its scope, what it did, when, and on whose behalf — no separate forensic exercise required.
  • Onboarding is a documented, repeatable process — not a Slack thread. What used to be a one-off email negotiation becomes the same shape every time.

The result: "what partners' agents have access to our system, with what scope, and what have they done?" is a one-query answer. Compliance is happy. Security is happy. The partner is happy. Your sales team is very happy.

The scenario this is built for

Picture a large enterprise that wants its procurement-automation agent to query a producer's pricing dataset on a six-week contract. The conversation between sales, security, and engineering would normally be weeks of back-and-forth. With external-agent access, the partner brings their identity in on a Friday afternoon. By Monday lunch, the contract is countersigned and the agent is live, accessing exactly the two datasets it's scoped to. Six weeks later, when the contract ends, you revoke access in one action on your side — the agent's identity and its scope disappear together. No follow-up. No "did anyone clean that up?"

That's not magic. It's just the integration finally being shaped like the contract instead of the other way around.

Why the trust model matters

The most important detail here isn't a feature — it's the trust model. The partner is responsible for their own identity. You're responsible for what you grant on top of it. The two responsibilities are clean and separate:

Reduced liability. When a secret is shared between two parties, a leak could be either party's fault. When the partner controls their own identity, the surface where you can be blamed for their lapse shrinks dramatically.

Faster onboarding. No "let's securely deliver a key" call. The partner brings their identity, you grant scope, the agent is live. The technical part of partner integration becomes minutes, not weeks.

Cleaner revocation. You can revoke on your side. They can rotate on their side. The two operations don't have to be coordinated — which is exactly what you want when relationships end on tight timelines.

What this enables

Three patterns follow:

Faster partner onboarding. What used to be weeks of negotiation becomes a day or two. The technical part is small; the legal/contract part is what's left, which is appropriate.

Bigger partnership ambitions. When external integrations are easy and safe, companies do more of them — partnerships that would have been declined in the past because the security cost was too high become viable.

Cleaner partnership dissolution. Contracts end. Partners get acquired. Strategy shifts. Being able to revoke an external agent's access cleanly, without coordinating with the partner, is unexpectedly valuable when the relationship needs to end on a tight timeline.

The pattern is solvable

The conversation about external agent access doesn't have to be a "no" from security or a "yes" from sales that becomes a problem later. With the right primitives, it's a "yes" that everyone is comfortable with.

Go deeper

External-agent access is one part of Helix's agent control plane — per-agent identity, scoped tokens, policy, and a kill-switch: helix.tools/#agents.