Security and trust boundaries
Last updated October 21, 2026
This is a working draft prepared for the AgentPlane pilot program. It must be reviewed by qualified counsel before it is relied on or offered to customers.
01What is protected
AgentPlane protects actions that pass through a supported enforcement point. Every such action needs a decision that is signed, unexpired and bound to the tenant, agent, decision id and a hash of the exact payload. We do not describe the system as tamper-proof.
02Trust boundaries
- The monitored agent is outside the boundary. It cannot edit its policy, delete audit events, approve its own action or reach the kill switch.
- The decision point evaluates and never executes. The enforcement point executes and never decides.
- Tenant scope comes from the server session or agent credential, never from the request body.
03Controls in this build
- Deterministic policy engine with hard-deny precedence and no implicit allow.
- Approvals bound to payload hash and policy version, with expiry, replay protection and a ban on self-approval.
- Hash-chained audit events with a verification endpoint, and redaction at write time.
- Agent credentials stored as hashes and revealed once. Rotation invalidates the old key at once.
- Per-agent rate limits, request size limits, and a uniform error format without stack traces.
- Agent-level disable and an organization-wide kill switch that both reject new requests and block pending execution.
04Outage behavior
- Policy store unavailable: requests are denied. There is no fail-open path.
- Verifier failure: the execution is marked failed and an alert is raised. It is never reported as successful.
- Adapter failure: the execution is recorded as failed with an error code.
05Known limits
- The pilot build keeps state in memory and uses a demo session in place of single sign-on. It is suitable for sandbox evaluation only.
- Risk thresholds are initial defaults and have not been validated as safety boundaries.
- Actions that bypass the enforcement point are not governed.
06Reporting a vulnerability
Send details to [email protected]. We acknowledge reports within two business days and will not pursue good-faith research that respects user data and service availability.