Learn · Multi-client operations
One shared credential, many client accounts — how do you pin the right one?
Last updated:
In short
Workspace-to-resource binding pins a client workspace to one specific account, property, or site inside a shared credential — not just to the credential itself.
Agencies often use one shared or agency-wide login that can legitimately reach every client's account: a Google Ads manager (MCC) login, a shared Meta Business Manager, one GA4 or Search Console owner account. The credential is valid for all of them. Resource binding is the policy that stops a workspace from touching any account except the one it was approved for — the wrong target ID is denied before the credential is ever used.
One credential, many resources
Most agencies don't hold one credential per client. They hold one shared, agency-wide login that reaches everyone: a single Google Ads manager account sees every client's customer ID, a single Meta Business Manager reaches every client's ad account, one GA4 login can pull data from every property the agency manages. That's efficient — and it means a single valid, authorized credential is capable of touching accounts it should never be pointed at on a given task.
Why this is a different risk from wrong-client access
Wrong-client access happens when two different, client-specific credentials get crossed — an agent working in client A's workspace ends up using client B's key. Workspace-to-resource binding is a different setup entirely: there's only one credential, and it's legitimately valid for every account it can reach. The failure mode isn't "the wrong key was used" — it's "the right key was aimed at the wrong target." Both problems need policy enforcement; they're checking different things, and a system built to catch one doesn't automatically catch the other.
The clearest example: Google Ads manager accounts
Google Ads makes this concrete. A manager (MCC) account calls the API on behalf of any customer
account beneath it. Every request carries a login-customer-id
header identifying the manager, a developer token, and a separate target customer ID identifying
the specific account the call is actually about. The manager login is valid for all of them —
nothing in the credential itself limits which customer ID a given request may name.
Resource pinning closes that gap: each client workspace is approved for exactly one target customer ID, and a request naming a different one is denied before the credential is ever applied — even though the manager login could technically reach it.
Telling an agent which customer ID to use is instruction. Rejecting every mismatched customer ID before the credential is used is enforcement.
The same pattern elsewhere
The same shape shows up anywhere one login legitimately spans many client resources: a shared Meta Business Manager and its ad accounts, a GA4 login and its properties, a Search Console account and its verified sites. The fix is the same idea — bind the workspace to the one resource it should use. Google Ads manager-account pinning is the model we've tested most thoroughly; treat the rest as the same pattern applied per platform, not yet proven to the same depth.
How Outloop binds a workspace to one resource
Each workspace carries a resource mapping alongside its credential access — the specific customer ID, ad account, or property it's approved for. When an agent requests an action, Outloop checks that the request's target matches the workspace's approved resource before the credential is used at all. A mismatch is denied by policy, the credential is never touched, and the attempt is written to a redacted local audit either way. See Outloop for AI marketing agencies and how to connect the Google Ads API to Outloop.
A request is checked against the workspace's approved resource before the credential is used
- 01
Agent request
The agent asks for an approved action or alias — not a raw key.
- 02
Policy & tenant check
Outloop checks project, tenant identity, and runtime policy before anything runs.
- 03
Local broker
On approval, the local broker uses the credential on the wire to perform the call.
- 04
Redacted result
The agent receives a sanitized, non-secret result. Raw values never enter its context.
- 05
Audit log
Every attempt is written to a redacted local audit — decision, tenant, service.
The agent never sees the credential. A wrong-tenant request is denied at the policy check, before any backend call.
Sources
Related: wrong-client access in agent loops, managing API keys across many agent workspaces, Outloop for AI marketing agencies, and Outloop for AI agencies. Outloop is available with guided onboarding for agency teams; the local app is verified on the founder's Mac; Apple signing/notarization and second-machine reproduction are still in progress.
One shared login. The right account, every time.
Outloop is available with guided onboarding for AI agencies, operators, and dev shops.
Start 14-day guided trial