Security model

A manifest describes tools; it never ships executable code. When a doer agent's tool is called, the shared @findagent/mcp runtime — not the agent — performs the action, from a fixed, auditable set of binding kinds: an http request or a prompt-template. There is no “run-this-code” action. Multi-agent coordination (one agent calling another) is served by a Department, not a tool action.

Because there is no agent-supplied code to execute, installing a declarative agent cannot lead to remote code execution. The runtime is the only thing that runs, and it is trusted and the same for every agent. A skills bundle is declarative too — each skill is Markdown the runtime serves as a prompt, never code it runs. The one kind that does run real code, a code agent, is isolated in a sandbox (covered below).

Every submission is scanned before it can go live, and the scan fails closed — anything it can't verify as safe is rejected rather than waved through:

• Host allowlisting. A tool's HTTP action is checked against the hosts it is allowed to reach.
• Credential binding. A credential slot must declare allowed_hosts; the scan verifies that an action's auth_ref resolves to a slot whose audience matches the action's destination. A credential with no audience is rejected.

At execution time the runtime enforces the same boundaries the scan checked, plus network hygiene:

• Outbound calls are restricted to secure connections.
• A credential is only attached to a request whose destination host matches the slot's allowed_hosts — so a secret can never be sent to an unintended host. This holds for every attach scheme (a Bearer token, HTTP Basic, a raw Authorization value, or a custom header), and a cross-host redirect strips the credential header rather than forwarding it.
• A self-hosted target whose host isn't known until install (a company's own GitLab or Jira Server) uses an install_host slot: the host the buyer types at connect time becomes the slot's audience, and the runtime resolves it only from that stored value — a caller can't widen it, so the secret still only ever reaches the one entered host.
• Egress is guarded so a tool can't be tricked into reaching internal or unexpected addresses, and redirects are not followed blindly.

A doer agent's manifest may declare guardrails, but the FindAgent gateway — not the agent's code — enforces them on every serve path (hosted, local, code-bundle, and department-to-department). A creator can only tighten a rail; the mandatory ones can never be turned off:

• Output secret-leak scan (mandatory). Every tool result is scanned for leaked secrets before it reaches the caller, and a manifest that tries to disable the scan fails validation. Optional pii_redaction can additionally strip personal data from the result.
• Input rails. Payload-size caps, a prompt-injection deny-list, and optional PII redaction run before a call reaches the agent.
• Action rails. A write can require human approval (human confirms where the client can prompt; human_strict fails closed when it can't); a destructive tool gets an approval floor by default. A spend-cap, a rate limit, and an order rail (requires — tool B may only run after tool A ran recently) round it out. These are real gates, not prompt advice.

The exact shape of each rail is on the manifest spec — this page is about why they hold regardless of what an agent tries to do.

For a locally installed agent, credentials you store stay on your machine and are attached only to allowed hosts. For a hosted agent, access is tied to your FindAgent account through a sign-in you approve once and can revoke anytime — there is no token to copy around.

If a published agent, a review, or a comment violates the marketplace policy, you can flag it for moderation. A report routes the item to admin review, where it can be resolved or taken down — the same gate that keeps the catalogue safe at submission time keeps it clean after publish.

Some agents run real code rather than declared tool bindings. A code-bundle agent never runs on your own machine — instead its code runs server-side in an isolated, ephemeral sandbox that FindAgent provisions for each run (a per-run microVM), walled off from FindAgent's own app and data. The sandbox enforces a default-deny egress allowlist — the only hosts it may reach are the ones its manifest declares.

A creator brings a code agent through the GitHub-connected submit flow: the bundle is snapshotted, statically scanned, and human-reviewed before it can publish, and a manifest the sandbox can't accept fails closed rather than being waved through. Importing an arbitrary public repo as a code agent is an admin-only seeding path.

Honest boundaries build more trust than a wall of green checkmarks. The guarantees above are about safety boundaries, not quality or third-party behaviour:

• They don't promise an agent is bug-free or that its results are correct — read reviews and try an agent before relying on it.
• The output secret-leak scan catches accidental leaks; it can't promise to stop a deliberately malicious code agent from encoding data around a text scan. The real boundary there is the sandbox's default-deny network allowlist, which blocks any host the agent didn't declare.
• FindAgent doesn't vet the third-party services an agent connects to — once your request reaches an external provider, that provider's own security and privacy apply.
• For a listing-only MCP server (a pointer to a server the provider runs), FindAgent doesn't run or inspect that server — you connect to it directly with the provider's own sign-in.

• Security overview — the plain-language, buyer-facing version of this model.
• Manifest spec — credential slots, allowed hosts, tool actions, and guardrails in detail.
• Creator guide — what the review and scan pipeline rejects.