Six boundaries worth keeping
sMCP makes the trust, consent, privacy, and execution rules around an agent explicit. These practices describe the DiviDen reference implementation. Read the wire specification for the public contract and the configuration notes below for enforcement details.
01 / Check where a request goes
An endpoint supplied by an agent is untrusted. The outbound guard checks the URL, resolves the hostname, rejects private and metadata networks, and pins the approved address. Each redirect gets checked again. This closes the gap between checking a hostname and connecting to a different address after DNS changes.
Keep these checks around every outbound hop, including discovery, verification, and execution. A conforming response does not make an arbitrary network destination safe.
02 / Keep secrets behind the boundary
The credential resolver returns connection status and metadata, never key material. A public manifest describes capabilities, schemas, and requirements; it does not carry credentials or private dispatch details. Resolve credentials at execution, in the component authorized to use them.
Give the model an allowlisted, structured view of capabilities. Publisher descriptions and free-form instructions are untrusted content, not permission to act.
03 / Guard the return
Treat the agent's response as another untrusted boundary. The return guard is deny-by-default and fail-closed: a failed assessment does not silently release content to the user. Deterministic checks can be supplemented by a configured model-based assessment.
Apply this to every returned value, even when the agent has a good reputation. Permission to run does not certify the result.
04 / Bind consent to the work
An approval binds the manifest fingerprint, task, canonical input, scopes, and charge ceiling. The broker recomputes that binding at dispatch. If any element changes, the run needs fresh approval. Approvals are time limited and single use.
Whole-run consent is the active default. Field-level, time-limited, revocable grants are implemented behind an optional enforcement flag. A one-time run does not implicitly permit persistent memory. Try changing an approved request.
05 / Sign the declaration
An Ed25519 host attestation signs a manifest fingerprint. Verification uses the registered public key and checks whether the current manifest has drifted. A matching SHA-256 fingerprint alone does not establish a valid signature or a trusted host.
Host-attestation enforcement depends on configuration. The verification lookup exposes the reference node's current evidence, including drift, instead of treating every badge as a blanket approval.
06 / Let trust earn its way
Autonomy progresses through observe, suggest, ask-once, and auto. Reputation is scoped to the user and domain, decays over time, and remains visible to the operator. The trust gate can relax an existing requirement when the configured conditions are met; it does not secretly grant unlimited authority.
Keep permission checks at dispatch even when a familiar agent is doing familiar work.
Read the implementation precisely
The wire contract is a draft, and deployments may enable different controls. Distinguish a capability declared in the specification, evidence reported by a node, and a control enforced for an actual run. Review all three before integrating.
Read the complete specification or inspect the public discovery documents.