AI agent permission models: allowlists, sandboxes, and credential gates
Give an agent broad access and you get a capable assistant. Give it broad access with no permission model and you get a capable assistant that can also exfiltrate every key on the machine. The question is not whether to restrict your agent — it’s which restriction model fits which risk.
Three models dominate practice: allowlists, sandboxes, and credential gates. They solve different problems, and a serious setup uses all three.
Allowlists and denylists
The simplest model: the agent may invoke only the tools or commands on a list.
Allowlists are precise — the agent can run git diff but not curl — and
they are easy to reason about. They also fail in predictable ways. First, an
allowlist of tools does not control what the tools do: pushing to a new remote
or reading ~/.ssh/config is still a single allowed command. Second, the list
grows and drifts over time. Third, allowlists say nothing about data — a
permitted tool can still print a secret into the context window.
Sandboxes
The second model: run the agent where the damage is contained — containers, seccomp filters, network namespaces, read-only filesystems. Sandboxes are strong on blast radius: a compromised agent inside a container cannot touch your SSH keys. But sandboxes are coarse. The agent still needs network access for most real work, which means the interesting channels — model API traffic, credential use — pass right through. And secrets must still cross the boundary when a subprocess inside the sandbox needs them.
Credential gates
The third model operates on data rather than tools: the agent never holds a plaintext credential. A broker resolves secrets from a store at the moment they are needed — injecting into a subprocess environment or an HTTP request — and the agent only references secrets by name. Output is scrubbed so values do not leak back into context, and a DLP layer masks secret-shaped content in outbound model traffic. A credential gate does not stop the agent from running a destructive command; it stops the agent from ever possessing the keys that would make that action catastrophic.
Layering, not choosing
Consider a concrete scenario. An agent with an allowlist runs git clone on a
repository the user points it at. The repository contains a malicious hook or
a README with injected instructions. The allowlist permitted the clone; the
sandbox contains the blast radius only if the hook cannot reach the network or
the keyring; the credential gate decides whether the hook finds anything worth
stealing. Each layer answers a different question: what can it do, what can it
break, what can it take.
The models are complementary. An allowlist limits what the agent can do; a sandbox limits what it can break; a credential gate limits what it can steal. An allowlist alone still exposes keys to prompt injection. A sandbox alone still ships context — and whatever secrets it contains — to a model API. A credential gate alone leaves the agent free to destroy files.
Realistic deployments stack all three: allowlisted tools, a container or restricted user for the agent, and a credential broker handling every secret. That last layer is where trustless sits — a zero-dependency Go binary that reads your existing pass or Bitwarden store, injects credentials into subprocess and HTTP flows without exposing them, scrubs tool output, and keeps an append-only audit log of every resolution. The full command set is in the documentation.
Which layer is missing in your setup — and how would you know if a prompt injection was already inside it?