When our first users signed up, an agent job ran daily against our production database. It checked for new Golemry signups, looked up each user's onboarding state, and drafted a matching follow-up email. Unattended, against live customer data. Once the logic stabilized, we demoted the job to plain code, because it no longer needed AI judgment. But in the weeks it did, we could only run it like that because of the architecture below.
If you're building an agent product, letting an agent do that should make you slightly nervous. An agent is non-deterministic and can be steered by its inputs, so the security question isn't whether it will always behave. It won't. The question is what a misbehaving run can actually reach. The principle to build on: structure over behavior. Anything that depends on the agent following instructions is a suggestion. What counts are walls, things a run cannot do no matter how confused or manipulated it is.
The four walls below apply to any agent stack. For each, we'll show how we build it at Golemry, where the tool layer, 900+ connectors, runs on Composio: it handles OAuth flows, token lifecycle, and webhooks per provider, keeps credentials in vaults, and executes tools sandboxed on its own infrastructure.
1. Keep account tokens off the agent machine
The account tokens themselves, Gmail, Slack, whatever your users connect, should live on a different machine from the agent. When a run needs to send an email, it does not hold a Gmail token and call Gmail. It asks a service that holds the token, and that service makes the call. A prompt-injected agent can't exfiltrate what was never there.
That machine is not credential free, though. It still holds whatever authenticates the agent to that service, plus the model provider key and anything else the run legitimately needs. Design those for blast radius: scoped to a single user, easy to revoke, time-limited where the provider allows it. Not in environment variables, and behind a process or sandbox boundary from anything the agent steers.
In our setup, Composio holds the account tokens: we delegate the whole OAuth flow, they land in a vault, and tool calls execute sandboxed against it on Composio's side. What crosses to the agent machine is a single project API key, good for one user's project only, revocable in one step.
2. Give every user their own vault
If your product is multi-tenant, the second wall sits between your users. Every user's connected accounts should live behind their own hard boundary, so one user's runs cannot see another user's connections, credentials, or events, even if your queries get it wrong.
Our implementation: every Golemry signup gets its own Composio project, with its own vault, connections, and triggers, provisioned programmatically. It costs a project per user and a fleet of keys to manage. It buys the strongest isolation primitive available. We've run this pattern in production for months.
3. Fix the toolset before the run starts
Scope tools per job, not per user, and scope at the tool rather than the connector wherever you can: a job that needs read-Gmail and write-Sheets should hold those two tools, not all of Gmail and all of Sheets. Whatever the set, it is fixed when the job's agent is instantiated, before it runs a single step. Nothing mid-run can widen it. From inside the run, tools outside the scope don't exist. A confused run can't wander into Slack, because there is no Slack.
This wall earns its keep twice. Against an attacker, it caps what an injected run can operate. And with no attacker at all, it protects you from your own agent, doing something it technically had access to but never should have touched. In Golemry, the scoping is enforced on our side, per job, at instantiation. It is the step most setups skip, handing the agent whatever is installed and calling it configured.
4. Sandbox every tool call
An agent that can run code can run any code. Whatever executes locally, shell commands, file writes, a script the agent wrote thirty seconds ago, should run inside a sandbox rather than as a process holding your machine's privileges. Otherwise a single injected instruction inherits everything that process can touch: the code you deployed, the environment it booted with, whatever else shares the box. Make it mandatory rather than best effort, and verify it at runtime, because isolation that quietly stopped working looks identical to isolation that works.
In Golemry, every local tool call executes through bubblewrap, in a workspace created for that run and thrown away with it. Tool code is mounted read-only, and the agent's own application directory is not mounted at all. Before a run does any work it probes its own sandbox, checking both that isolation is live and that it cannot see the agent's code, and refuses to start if either probe comes back wrong.
Outlook: from secure to safe to reliable
Security is the floor, not the goal. Walls bound what a run can reach, but they can't tell you whether the run was any good. A job that legitimately holds send-email can still send a bad email. A run can report success while the work behind it quietly failed. Inside the mandate, "bad" is a judgment, not a rule. Three rungs, not two: secure is no breach, safe is no harm, reliable is the work actually being right. Walls buy the first. The other two are judgment, every run.
That's the layer we build on top of these walls in Golemry. An independent overseer reads every run, including the ones where the input tried to steer the agent, and escalates what looks off, so a manipulated or derailed run doesn't ship silently. Walls for what can be made impossible, oversight for what can only be judged.
But build the walls first. They're the floor that let us point an unattended agent at our production database (with read access), and would let you do the same.
