Skip to content
Documentation menu
Reference

Security model

Installing a third-party agent should never mean running someone else's code on your machine. Most agents on FindAgent are declarative — they describe what to do, and a single trusted runtime decides how to do it safely. The one exception, a code agent, never runs on your machine: it runs in an isolated sandbox.

Declarative-only: the keystone

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, a prompt template, or a call to another agent).

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

The static scan

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.

Runtime safeguards

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.
  • Egress is guarded so a tool can't be tricked into reaching internal or unexpected addresses, and redirects are not followed blindly.

Credential custody

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.

Reporting abuse

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.

The code-bundle sandbox

Some agents run real code rather than declared tool bindings. A code-bundle agent never runs on your machine as part of a normal install and never on FindAgent's own infrastructure — its code runs in an isolated, throwaway sandbox with a default-deny egress allowlist, the only hosts it may reach being 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.

In one line
Declarative agents ship no code, so installing one can't execute anything. Code agents run only inside an isolated sandbox — never on your machine and never on FindAgent infra — and only after a scan and review.

Related

  • Manifest spec — credential slots, allowed hosts, and tool actions in detail.
  • Creator guide — what the review and scan pipeline rejects.