An integration broker can remove a substantial amount of engineering work from an agent platform. It can manage connection flows, credential storage, token refresh, and provider-specific authentication behavior. Those capabilities make it easier for a customer to connect the systems in which an agent needs to work.
The connection answers an important question: can the platform authenticate to this provider on behalf of this account? A separate decision remains: may this particular agent perform this operation on this resource for this task? Production architectures need both answers, with a clear boundary between them.
Understand what the connection actually grants
Provider scopes are usually designed around API capabilities. They may allow reading files, creating issues, or sending messages across a broad account. The customer's business requirement is often narrower: read documents from one project, update one issue queue, or draft a message without sending it.
An OAuth scope is therefore an outer limit on available capability, not a complete description of delegated authority. A token with mail access does not express which recipients are acceptable, whether confidential attachments are allowed, or whether a support agent may send on behalf of an executive. Those constraints belong in application and resource policy.
Nango's auth guide describes managed authorization and credential handling [1]. An integration broker is a sensible component when those capabilities fit the deployment. The security architecture still needs to account for who may retrieve a credential, invoke a proxy, select a connection, and change the mapping from an agent to an account.
Keep four identities distinct
Identify the customer organization, the human delegator, the agent workload, and the provider account. A service agent may act under a shared operational account while individual employees initiate tasks. Losing those distinctions makes both authorization and incident reconstruction harder.
Use trusted server-side mappings to resolve them. A client-supplied organization header is not proof of tenancy. A model-generated agent name is not a workload credential. A provider account ID should not be selectable from arbitrary tool arguments without an ownership check. Resolve the connection against the authenticated organization's permitted bindings before making a downstream call.
Also represent the principal that administers the integration itself. Changing a connection from a test workspace to the production workspace can be more consequential than the next individual tool call. Treat connection edits, scope expansion, and reconnection as privileged configuration changes with their own audit trail.
Put policy before credential use
A strong brokered execution path receives a normalized action, resolves the authenticated agent and connection, checks business policy, and then invokes the provider using a credential the agent does not need to see. The decision record should identify the policy revision and the target that was actually used.
If raw provider credentials are returned to the workload, the control surface changes. The workload may call the provider directly, outside the broker's policy and audit. This may be acceptable for some deployments, but it cannot support an unconditional claim that every action is mediated. Document the bypass and use provider-side permissions, network controls, or controlled execution to close it where necessary.
For MCP over HTTP, use the protocol's authorization model rather than treating a third-party token as a universal bearer credential [3]. Validate the intended resource and issuer according to the deployment. Keep downstream credentials separate from the token authenticating the caller to the MCP service.
| Layer | Question | Evidence |
|---|---|---|
| Provider consent | What may this account connection access? | Granted scopes and account identity |
| Workload identity | Which agent is making the request? | Validated workload authentication |
| Business policy | Is this action within delegated authority? | Resource, task, limits, policy revision |
| Execution | What actually happened downstream? | Provider request ID and confirmed outcome |
Make token lifecycle part of the threat model
Refresh is operationally convenient and security-sensitive. A revoked agent should not regain access because a background refresh succeeds on a still-active shared connection. Distinguish disabling the workload, removing its connection binding, revoking provider credentials, and deleting cached authorization decisions.
Plan for scope changes. Providers differ in incremental consent, token issuance, and refresh behavior. Verify the granted scopes and provider account after reconnecting; do not assume that the scopes requested by the application are exactly what the provider returned. Present unexpected expansion to an administrator before restoring the connection to normal use.
RFC 9700 consolidates OAuth security recommendations, including protections against token theft and authorization-flow attacks [2]. Apply those requirements in the component that owns each step. Outsourcing the OAuth flow reduces custom code; it does not eliminate responsibility for secure connection selection, administrative permissions, or credential exposure in logs.
Evaluate the broker as infrastructure
Review isolation between customers, key management, supported deployment models, credential export behavior, audit events, revocation semantics, and operational failure modes. Establish which guarantees are documented and which require an integration test. A feature list is not evidence that the end-to-end path meets your threat model.
Decide what happens when the broker is unavailable. Consequential actions should stop or queue with bounded retention according to the workflow. Retrying must not duplicate an external send, refund, or state change. Use the provider's supported idempotency mechanism when available and reconcile ambiguous timeouts before issuing the action again.
Keep secrets out of model context, approval notifications, and routine traces. Record a stable connection identifier and a masked account label instead. If a diagnostic export can include credentials, make that an explicit privileged path with short retention and an audit event.
Prove the boundaries with integration tests
Test cross-tenant connection substitution, disabled agents, stale credentials, revoked provider grants, expanded scopes, changed recipients, and retries after partial failure. Confirm that a request denied by business policy never reaches the provider. Confirm that the provider account used matches the one the reviewer expected.
Run these tests whenever connection routing, broker configuration, or policy compilation changes. The highest-risk bugs often live between individually correct components: identity resolves one tenant, policy checks another connection, and the broker executes against a default account.
A broker can be the right choice precisely because authentication plumbing is difficult and repetitive. Let it do that job well. Build and verify the authority layer around it so a convenient connection becomes a controlled capability rather than a permanent, broadly usable credential.