The product
One controlled environment for client AI work.
Outloop is not one feature. It is eight layers that have to hold together for an agent to finish a real client task — and the layer that keeps them holding.
Last updated:
In short
Outloop is the access and control layer for AI agents doing client work.
It runs on a computer your company controls. Agents start from approved client context, use approved API access without ever seeing the credential, stay bound to the correct client account, move real files, and leave a redacted audit trail. Any lesson learned becomes a change only after a person approves it.
Reuse approved API access across the runtimes your team already uses
One approved access layer for Cowork-style sandboxes, Claude Code, Codex, Hermes, and OpenClaw — without rebuilding setup for every platform.
One credential. The right workspace. Any approved agent runtime. secret_exposed:false
Independent tools. Names and logos belong to their respective owners; Outloop is not affiliated with or endorsed by these projects.
The eight layers, and what each one is for.
Each layer carries its own evidence label. Where something is built but not yet broadly proven, it says so.
- 01
A company-controlled computer
shippedOutloop runs on a Mac your company controls — a dedicated remote machine is the recommended starting point. Outloop does not supply or host that machine.
Local-first describes the trust boundary, not where the desk is. Execution authority stays on your side of it.
Cloud agents vs dedicated machines - 02
Client context
proven in productEach client workspace holds its own approved knowledge — brand and tone guidance, approved references, communication rules, constraints on what may be claimed. The agent retrieves it before it generates anything.
Otherwise every run starts blank and a person re-explains the client from scratch. Context is knowledge only; it never grants API permission.
Context and governed learning - 03
Client identity
shippedA workspace is derived from the real project folder and maps to exactly one client. A new workspace starts with no grants and no API access.
The agent has to know who it is working for before anything else is safe.
Wrong-client access - 04
Approved access
proven in productThe agent requests an approved action, not a secret. Policy checks tenant, project, service and host; the local broker uses the credential host-side and returns a redacted result.
The agent gets the capability of a credential without ever receiving its value.
Agent runtime access - 05
Account and resource binding
verified for the tested modelOne agency credential can legitimately reach many client accounts. A workspace is pinned to the specific account, property or folder it may use, and a request naming another is denied before any backend call.
A Google Ads manager login can reach every account under it. Pinning is what makes one credential safe across many clients.
Workspace-to-resource binding - 06
Files and media
proven within tested scopeAgents work with real client files through approved paths — Drive and Shared Drives, approved local media roots — including large media transfers to approved business platforms.
Agents that can write a caption but not move the video hand the work back to a human at the last step.
Real client file work - 07
Audit
shippedAllowed and denied attempts are both written to a redacted local audit — decision, tenant, service — with no raw values.
You can answer what ran, for which client, with which access, without storing a secret to do it.
Security model - 08
Governed learning
proven in productAfter a run the agent can propose a lesson as a structured receipt. A person approves, edits, rejects or defers it. Only an approved lesson becomes a new Context revision, and revisions are versioned and restorable.
Improvement without a review step is just drift you cannot audit. Nothing updates itself.
How learning is reviewed
One request, from ask to audit.
Layer 04 is where most of the confusion lives, so here it is in full.
What happens when an agent asks to do something
- 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.
What Outloop is not.
- A vault or a secrets manager — Outloop sits above the one you already use.
- A cloud agent host — the agent runs on your machine, not ours.
- An MCP marketplace or an MCP manager.
- A campaign automation or reporting tool — the agent does the work; Outloop controls the access.
- A replacement for 1Password, Infisical, Doppler or macOS Keychain.
More on the boundaries: Outloop is not a vault · credential broker vs MCP authentication · the long-term thesis.
Keep your vault. Control runtime access.
Outloop works above Keychain, 1Password, Infisical, Doppler, and other secure backends. It does not replace your vault. It controls which workspace and runtime can use approved access.
- No API keys uploaded to cloud.
- No raw key returned to the agent.
- No .env files required.
- Wrong-client access is blocked before credential use.
See it on one of your own client workflows.
Start the guided trial and run your first approved access proof locally — or send us one workflow and we will show you where the access breaks.