Security model

A manifest describes tools; it never ships executable code. When an agent's action 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. Skills are declarative too — Markdown served as a prompt, never run. The one part that runs real code, an agent's code, is isolated in a sandbox (covered below).

Every agent FindAgent serves 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. An mcp-server listing has no FindAgent-side code to scan, so it is published on the human review alone:

• 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.

An 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 FindAgent token to copy around. Any keys the agent needs from you for another service are entered while you connect, stored encrypted, and bound to the hosts its manifest declares.

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.

Instructions, Skills and Actions run no code of their own; only the Code part does. When the Code part is hosted (a code-bundle in the manifest), it never runs on your own machine — instead it 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 may instead (or also) offer the Code part local: you download it and run it on your own machine, with your own access. FindAgent never runs it and enforces no network limits there, so the sandbox described here does not apply — review the source before you run it. See The Code part of an agent.

A creator brings the Code part through the GitHub-connected submit flow (Code needs a GitHub repo for now. Upload and the Editor carry the other three parts; see the creator guide): the repo 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. Only a repository the creator can push to is accepted as an agent's code.

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.