Why this decision exists. Four problems show up in production.
Writing one connector is straightforward. Running connectors for every customer, across providers, under security review is the hard part.
Agents need to act as specific users
A shared service account writes as the bot everywhere: approvals keyed on user identity break, and attribution is gone. Reviewers expect delegated, per-user OAuth grants.
Scopes are enforced per tool call
Every tool call needs a scope check: this agent, on this connector, for this customer. That check belongs in the request path, not in an instruction in the prompt.
Every connector authenticates its own way
OAuth 2.0, API keys, JWTs, service accounts: every connector picks its own. Then the provider quirks: 401s that mean three different things, refresh tokens some servers never issue, workspace identity in a token here and a claim there.
Audit evidence gates the deal
Security reviews want per-action logs: who authorized, which agent, which tool, what came back, streamed to a SIEM. Without them, one overnight failure means grepping four log sources by hand.
Eight criteria for the decision. Score the product you ship this year.
Answer for the product you are shipping this year rather than long-term plans. Selections stay in your browser.
Answer the eight criteria
Your result appears when all eight are answered. A low score points to building, and the result will say so.
The scope of building it yourself. Fourteen components across four areas.
Most of these fourteen are missing from the first version teams ship. They arrive later, one customer request at a time, which is why estimates understate the cost.
| Component | Why it exists | If you get it wrong |
|---|---|---|
| ACredentials and identity | ||
| Per-customer credential vault | Each customer's token isolated from every other customer's | Cross-tenant access. A reportable incident |
| Credential boundary outside the agent runtime | A raw token in the execution loop reaches traces, logs, and model context | A live token in a log tool you do not control |
| Delegated OAuth per end user | Every downstream call attributes to the human who authorized it | No attribution, and a stalled enterprise review |
| Revocation propagation | An admin offboards someone and agent access dies with them | A former employee's agent still writing to production |
| BExecution and reliability | ||
| Refresh handling mid-run | Long agent tasks outlive the access token | The task dies partway through with writes already committed |
| Durable execution for long runs | Job queues, polling, and state that outlive an LLM request timeout | A ten minute tool call dies at the timeout with writes half applied |
| Error normalization per connector | APIs return 401 where 403 belongs, so the agent reads denial as an auth failure and retries | A silent retry loop. Rate limits burned, no signal |
| Zero-downtime JWKS rotation | Rotate keys without killing live sessions | A full agent outage during routine maintenance |
| CAuthorization | ||
| Scope enforcement before the API call | A model will not reliably respect a scope described in a prompt | A write the agent was never granted |
| Permission intersection at call time | The agent's scope and the user's own permissions both have to allow the action. Either one denying it is a denial | An admin invoking the agent silently widens what the agent can reach |
| DAudit, residency, and the spec | ||
| Per-action audit stream to a SIEM | Procurement asks for it by name | A blocked deal, or manual evidence gathering every audit |
| Correlated tracing across agent, runtime, and API | One run id tying the agent step, the token refresh, the retry, and the API response together | Four log sources stitched by hand to explain one overnight failure |
| Regional residency isolation | One EU customer contract | A contract you cannot sign |
| Protocol tracking | MCP client registration and discovery rules are still changing | Clients stop interoperating after a spec revision |
None of this is exotic. But a mistake here is a security incident, not a bug ticket, so the upkeep stays high for as long as you own the layer.
Who carries which risk. Including the two risks buying adds.
Buying transfers most of these to the vendor and adds two of its own: a new dependency in the tool-call path, and exposure to vendor pricing or ownership changes. Both are in the table.
| Risk | If you build | If you buy |
|---|---|---|
| Cross-tenant credential leak | Yours to prevent, yours to disclose | Per-tenant AES-256 vault, contractual |
| Token in model context or logs | Rests on discipline in every tool you write | Structurally prevented. Credentials resolve outside the agent runtime |
| Failed enterprise security review | Likely, on attribution and audit gaps | The evidence already exists |
| Failures with no human in the loop | Yours to detect and normalize per provider | Handled upstream of your code |
| Spec drift breaking clients | Yours, every quarter | The vendor's |
| Outage in the integration layer | Your infrastructure, your SLA | A new dependency. Needs an SLA and a fallback you have tested |
| Pricing change or acquisition | Not a factor | A real risk. Mitigated by a reversible rollout: one connector behind a flag first |
If you buy, what stays yours. Credentials, connectors, tools, auth, keys, and where it runs.
Buying the layer does not mean adopting someone else's stack. Check that each of these stays under your control, with any vendor.
Your OAuth apps
Bring your own app credentials per connector. Consent screens carry your brand, and tokens live in a vault isolated per customer.
Your connectors
Register connectors for internal APIs by defining the auth pattern and tool schemas. They behave the same way catalog connectors do.
Your tool surface
Trim or extend each connector's tool set. A per-user endpoint exposes only the tools that user is allowed to call, not the whole catalog.
Your identity provider
Bring Your Own Auth wraps OIDC, SAML, or a custom scheme and issues OAuth 2.1 tokens on top. Ships against any identity provider without moving user data.
Your infrastructure
Self-hosted keeps data, logs, metrics, and telemetry inside your perimeter. VPC and air-gapped deployments are Enterprise arrangements.
Your encryption keys
Bring your own key from your GCP or AWS KMS, so rotation, revocation, and the key audit trail stay with your team. Enterprise plan.
The rollout itself stays reversible: one connector behind a flag first, compared against your current path on live traffic, then the rest.
Questions to ask any vendor. Our answers, limitations included.
The questions that come up in security reviews and vendor evaluations. The list works as-is for evaluating any vendor.
Where do credentials live at the moment of a tool call?+
How quickly does revocation take effect?+
Can a privileged user widen what the agent can reach?+
Can we enforce our own policy conditions on a tool call?+
How does this support offboarding and access reviews?+
Can we manage the encryption keys ourselves?+
What leaves our perimeter, and under which deployment model?+
What happens to the integration work we have already done?+
What happens when a required tool is not in your catalog?+
Who absorbs API and protocol changes?+
Why not one shared connection per customer account?+
What happens to in-flight runs during your maintenance?+
What happens when a third-party API errors mid-run?+
What latency do you add, and what uptime is contractual?+
What does an audit record contain, and how long is it retained?+
What drives the price as we scale?+
What compliance evidence can you provide, and when?+
What does self-hosted deployment include?+
Which features are Enterprise-only?+
Take this into your decision doc
Copies your eight answers, the result, the fourteen components, and all nineteen questions as plain text for your internal decision doc.
