The multi-client marketing bottleneck
A marketing agency doesn't run one agent against one API. It runs agents across many clients, each with its own ad accounts, analytics properties, Merchant Center, and CRM. Every new client re-opens the same question — how does this agent reach that client's API safely? — and the risks stack up:
- →You're stuck hand-feeding API keys and re-doing access setup for every client.
- →Tokens sprawl across
.envfiles, chats, and project folders. - →An agent can push a budget change or a feed update to the wrong client's account.
- →There's no clean per-client record of what ran, for whom, with which credential.
One approved access setup, reused across every client
Outloop changes what the agent asks for: an approved action, not a key. The flow is the same for every marketing API:
- 1.Set up approved API access once — per marketing API, stored in your vault or keychain.
- 2.Assign it to the right client workspace.
- 3.The agent uses the approved API through Outloop — it requests the action, the local broker performs the call.
- 4.Wrong-client access is blocked by policy before any backend call.
- 5.Raw secrets stay hidden — never in chat,
.env, or logs. - 6.Every request is audited — a redacted, per-client record (
secret_exposed:false).
A brokered request: action in, redacted result out
- 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.
