# Security & trust
What Semel enforces, what crosses the boundary and what never does, how attribution and project isolation work, and how to keep tokens safe.
A plain-language trust model for evaluators: what Semel verifies, what your local harness can access, what data crosses the boundary, and what Semel never records.
## The execution boundary
Your coding agent and local reviewer skills run in your harness under its sandbox, permission prompts, hooks, and secret controls. Semel governs the brief/review/execution protocol and records durable state; it does not bypass or normalize local harness permissions. An agent acts only within its server-enforced scopes and project reach.
## Data sent vs. never sent
- **Sent to Semel** — the brief content and canonical sections you author, review findings, accepted answers, bounded checkpoint results, cited evidence, and the explicit operation inputs a tool call carries.
- **Excluded** — raw OAuth, named-token, trusted-auth, or provider credentials; chain-of-thought; arbitrary local files; bulk repository dumps; and secrets. A certificate contains hashes and execution identities, not brief text, question/answer content, checkpoint prose, source, or reasoning.
- **Local evidence** — context tools expose only server-authorized project sources and exact returned citations. The agent must not widen that into an unrequested upload.
> **Note:** Privacy-safe analytics record only a discovery/install/auth funnel. They exclude tokens, OAuth parameters/state, customer content, and workspace/project names.
## Human control is structural
Only a person can approve or reject a gate; decide, commit, rebase, or revert a proposal; mint or approve an execution grant; clear or destructively restart a review; administer credentials or workspace membership; change billing/spend; connect Slack, GitHub, or a tracker; consent to BYOK/provider terms; create public share links; write to Brain; perform Done Check; or invoke `/runs/:id/continue`. These actions are absent from the MCP registry rather than hidden behind a stronger scope. Linking an already-connected repository through `project_codebase_link` does not confer provider administration.
## Attribution & project isolation
Every action is attributed to its true actor while naming the accountable human. Agent activity is never displayed as if the human performed it. Workspace tenancy, scopes, project all-or-allowlist reach, active grant, epoch, fence, lease, and sequence are checked server-side. An allowlisted principal cannot create projects to escape its set; denied reads and writes return a typed boundary error.
## Token hygiene
Named tokens are shown once. Supply them only via environment variables, OS credential stores, or native secret references. Never paste one into chat, commit it, place it in a checkpoint, or print credential-store content during diagnostics. Preserve OAuth credentials on transient network/429/5xx failures; terminal refresh failures require one serialized human reauthorization. Revocation in Semel blocks the next request. See [Authentication & permissions](https://docs.semel.ai/authentication#revocation).
## Certificate verification
A completed session produces a signed certificate that binds the brief base/result hashes, exact skill pins, ordered epochs and checkpoint range, validation outcomes, and receipt hashes. Verify its signature and identities independently; do not trust an agent’s summary as proof.
## Skill distribution trust
Download the installer only from `https://docs.semel.ai/downloads/semel-install.mjs` and inspect it before execution. It trusts the production manifest at `https://mcp.semel.ai/.well-known/semel-skill.json`, verifies a pinned Ed25519 publisher key and release statement, then verifies the content-addressed bytes. Unknown key IDs, invalid signatures, mismatched hashes, incompatible protocol ranges, and malformed skill metadata fail closed.
Canonical page: https://docs.semel.ai/security