Secure Credentials · Secure Tools · Secure Agents
Trust & security
QuickAgents run in a secure operating environment with credentials, tools, web resources and MCP servers locked away from the agent itself. This process is similar to how the hyperscalers run their Agentic systems except fully customizable. We leverage cutting edge agentic security tools to ensure that the agents are as safe as possible at runtime, and in order to publish an agent in the Agentry it must pass a rigorous set of tests and scans to make sure no malicious code or instructions make it to your data.
Everything is open source and fully auditable, and constantly improved with existing published agents rescanned regularly using the latest techniques. Security isn't a product, it's a process and it is taken seriously here.
Many agents, one set of credentials
You configure an assistant or a coding agent once: the MCP servers you use, the keys that sign in to them, the commands it may run, and often a shell. Every agent you start from that configuration holds all of it, whatever its task needs. An agent that summarises a document does not need your repository token, but in that setup it holds it.
An agent takes its instructions from the text in front of it. Nothing in the model separates the task you typed from the page it fetched, the file it opened or the result a tool returned. A line planted in any of those can tell the agent to use a tool it holds: read a key, post it to a host, run a command. Every credential the agent holds is within reach of such a line, and every tool it holds is a way to move it out.
Run ten agents from that configuration at once and each is a separate way in to the same set of keys. An agent that follows an injected instruction reaches everything the other nine can. An MCP server whose tool description carries an instruction reaches every agent that loaded it, because a tool description is text the model reads too. Nothing in that setup says which agent used which key, so a review after the fact starts from one shared log with no boundary in it.
Each QuickAgent runs on its own contract
A QuickAgent declares in its manifest, agent.yaml, what it needs: the hosts it may reach, the paths it may read or write, the commands it may run, the secrets it needs by name, and the MCP servers it uses at an exact pinned version. Declared capabilities are a contract from the author: what the QuickAgent says it needs, and what policy and scanning check against. The registry cannot enforce them while your QuickAgent runs. The runner does: it compiles that contract into the run, and what the manifest declares is what the runner asks you to consent to.
agentry run compiles the manifest and your operator policy into one plan and starts one container tree for that run. The agent container sits on a run-scoped internal network and can reach two things: the MCP gateway, with a bearer token, and an egress proxy whose allowlist is the model endpoints your policy names. It mounts the plan and nothing else, never your workspace, and it holds none of the secrets the manifest declares.
The runner starts a gateway for that run, which loads the tools server and exactly the servers the manifest declared, each with its own tool filter, its own egress allowlist, only its own secret values, and its own environment. A declared host is reached through a relay the gateway opens for it; nothing else resolves from the server. The gateway refuses a tool result that looks like a secret before the model sees it. Files reach the tools container by declared path, read-only unless the manifest declares write, and a declared command runs from an image that contains the declared commands and nothing else to run.
Keys live in a profile keyed to one exact release — its name, its version and its archive digest — in a directory only you can read. The runner hands them to the tools container and to the declared servers for that run, never to the agent container, and never writes them into a plan or a receipt. No other QuickAgent can reach them, and a new version of the same QuickAgent starts over, with its own consent and its own keys.
In the desktop app
The app drives the same runner packages as the CLI: the same plan compiler, the same gateway, the same receipts. The contract is the consent screen, the app collects the keys in a form, and every run uses the agent container.
From the CLI
agentry run builds the container tree on your machine, under your policy. The CLI can also drive your own Claude Code or Codex installation as a host process instead of an agent container. The gateway is still the whole tool surface and the proxy the route to the model. There, though, they are configuration the runner asks that installation to honour rather than a network it cannot leave, and the receipt says so.
In the cloud
A hosted run is the same CLI on the platform's machine. The platform's worker renders one policy per run, with the platform's model endpoint as the proxy's only host, and creates the QuickAgent's container under gVisor. The run holds a credential of yours only when its release declares one by name. That secret, saved or entered for the run, is decrypted when a sandbox host takes the run, goes to the tools container or the MCP server that uses it and never to the QuickAgent's own container, and is deleted from the host when the run ends. It is not a machine of its own: a docker daemon shared with anything else is a kernel shared with the run's sandbox.
Every mechanism in force is named in the run's receipt, so what was enforced is recorded rather than asserted. The runner reference lists each contract line and the mechanism behind it.
None of this covers a QuickAgent installed into Claude Code, Codex or OpenClaw as a skill. There it runs on that application's own tools and MCP servers, the contract compiles to that application's tool allowlist, and enforcement is the application's.
What the registry scans before anything is installable
Publication is a gate, not a formality. A version is scanned on the exact bytes that will ship. Findings decide the outcome. A version whose findings are low or medium publishes automatically, with every finding on its report, unless a policy holds it. A high finding sends it to a person for review, and a critical finding rejects it. There is no flag, plan, or role that skips it. If a scanner errors or times out, or content goes unread, the version fails toward review rather than through. One lookup is the exception: a declared MCP server with no vulnerability data is a finding, and the daily sweep asks again.
Ten stages run against those bytes, and the trust document lists each one. Eight read the package, each from a different angle: what the archive contains, whether it carries a credential, whether any text is hidden or obfuscated, whether it matches known injection patterns, whether its scripts do what its manifest declares, what is known about its declared MCP servers, who published it, and how it differs from the version before. One is AI Review, and the tenth assembles the report the signature is made over.
In AI Review a model reads the manifest and every text file of the release, scripts included, against a fixed six-axis rubric with no tools, and returns a score per axis. Agentry's registry uses TypeSafe AI's Jev System One, and records the model id and a hash of the questions and thresholds with each verdict. Its findings never reject a release on their own. A review that fails, or answers out of shape, routes the release to a human reviewer, and the deterministic stages gate underneath it.
Scanning happens at publication, not at push and not at run time. AI Review also reads what the Builder's Drafter reads, before the Drafter's model does: the description, each search result, each page and each registry answer. The model is not given what AI Review flags or cannot scan. That scan covers the Drafter's inputs, not a release, and a draft is scanned at publication like any other.
What signing proves
Each published release is content-addressed, and we sign an in-toto statement binding that archive digest to the scan report that produced the decision, the ruleset version, and the policy in force. A verified signature means: these exact bytes are the ones this registry scanned and published. It does not mean the contents are benign.
agentry verify acme/incident-summarizer@1.4.2Current signing keys
- -_Ea_eEb6AVt8DSP · ecdsa-p256-sha256
The CLI pins these on first use and warns if they change. We rotate them with overlapping validity windows.
What this does not guarantee
Static analysis cannot prove a QuickAgent safe. A sufficiently novel injection technique will pass a scan that was written before it existed. We publish finding counts, the ruleset version, and the scan date precisely so you can judge the freshness of the check rather than trust a badge.
Because detection improves after publication, we rescan published versions when rulesets ship. A new high-severity finding quarantines the version, notifies the author, and raises an advisory. The advisory feed lists every one — what was found, which versions are affected, and what consumers should do. A quarantine stops new installs; it does not reach a copy you already installed.
Reporting a problem
A vulnerability in Agentry itself goes to security@secureagentry.net. SECURITY.md in the open-source repository sets out the coordinated-disclosure process and what to expect after you send it. Agentry is an open source project focused on security and we will do our best to address all reported issues, both with the application and any published QuickAgents.