Security model¶
This page states what ameesh v1 guarantees and what it does not, without rounding up. It follows ยง11 of the specification.
Guaranteed in v1, and not yet¶
| Guaranteed in v1 | Not yet (planned for v1.x) |
|---|---|
| An agent without a responsible human, or misplaced against its host's policy, does not run. | Isolation of agents from each other: in the local profile they share the same Unix user. |
| No irreversible or costly action without a valid receipt when it goes through ameesh's gate. This protects against mistakes and prompt injection, not against a malicious agent that shares ameesh's Unix user: such an agent can read business credentials, modify ameesh or its database. | The gate and business credentials under a Unix user distinct from the agents'; a network sandbox; an MCP proxy. |
| Receipts are bound to the action's digest, single use, and expire. | Strong non-repudiation for synced passkeys (the high level means a hardware key). |
| The registry of authenticators can be changed only by a reviewed pull request to the canon. | Provenance signatures on agents' messages. |
| A readable thread of every message that goes through ameesh. | Messages exchanged outside ameesh. |
Design choices behind these guarantees¶
- Authority is proven, never read. No text, from an agent or claiming to come from a human, carries authority. A human's approval is a signature over the exact digest of the action, made on their own device.
- The signing key is out of the agents' reach. Passkeys live in the human's authenticator; ameesh-approve runs under another Unix user or on another host; the token ameesh holds can request and fetch receipts, never sign them.
- The service recomputes what it shows. The approval page displays the action as read from the database, never the agent's description of it.
- Enrolment is a proposal. A new passkey becomes active only after a reviewed pull request to the canon and a sync from the trusted canonical branch. A sync never goes backwards and never re-activates a removed passkey.
- Fail closed. An unreadable or invalid canon, a refused or unevaluated placement, an unresolved responsible human, an accounting marker that cannot be written: each one closes new claims or new turns, never silently opens them. Running leases and turns are not killed by a canon problem.
- Unknown is not failure. An action whose outcome is unknown is never retried automatically; it is reconciled with the connector or decided by a human who explicitly assumes the risk of a duplicate.
- Approved source only. The canon is read at the merged commit of the canonical branch, through git objects; local edits and unpushed commits are reported, never used.
Known limits¶
- In the local profile, agents share ameesh's Unix user: they can alter the canon clone or the git configuration. Only a check made by an isolated component (ameesh-approve, under another user) is enforceable against a malicious agent. The database's monotonicity keeps the passkey registry from going backwards.
- The lease invariant (no process of an agent alive after its lease deadline) holds within a scheduling margin, measured by the tests; arbitrary suspension of a process by the operating system is outside the guarantee.
- In the cluster profile, each agent has its own pod, file system and processes, but agents still share ameesh's database role.
- Using subscription credentials for unattended agents on a server must be checked against each provider's terms; a host policy can refuse that credential mode.