Security model

Eniyan issues signed, scope-delegated identity credentials for people and AI agents. It does not host your agents, mediate their actions, or replace your entitlement system. The smallest possible surface, stated plainly — so it survives review.

Trust boundaries

Eniyan's trust boundary is credential issuance and verification. We verify an identity (a person via an audited peer-approval ceremony inside their organization — optionally upgraded with a biometric + document check — or an agent via a declaration chain anchored to a human operator), then issue a signed credential describing it. What the credential holder is allowed to do, and whether they actually do it, stays inside your systems. Eniyan never sits in the runtime path of an agent's actions uninvited. The local gates (eniyan-fs, eniyan-web) are an explicit opt-in that runs on YOUR machine: the gate asks Eniyan policy questions and the cloud answers with decisions — metadata in (root aliases, path hashes, domains), decisions out; content never crosses the wire, and the cloud never becomes the executor.

Credential lifecycle

1. Issuance — after a verified session, Eniyan signs a W3C Verifiable Credential (ES256 JWT) describing the subject, trust level, and scope.
2. Presentation — the holder (or your platform) presents the credential token to a verifier.
3. Verification — the verifier checks the signature and, for authoritative checks, calls Eniyan for live revocation state.
4. Expiry / revocation — credentials expire and can be revoked; revocation is always server-authoritative. When a human operator's credential is revoked, their agents either continue under a surviving co-operator (promoted automatically) or suspend behind a time-boxed admin adoption decision — a departure is never a silent orphan.

Signing & verification

Credentials are ES256 (P-256 ECDSA) signed JWTs in the W3C VC model. Any verifier can validate a credential offline by fetching the public JWKS at /.well-known/jwks.json, matching the kid, and checking the signature and standard claims — no Eniyan round-trip required for signature validation. For revocation state, call POST /v1/credentials/verify, which is server-authoritative.

What Eniyan does NOT do

Stating boundaries plainly is the point — these are deliberate non-goals, not gaps:

• It does not sit in your agents' execution path by default — the local file and web gates are explicit opt-ins that run on your own machine, with Eniyan answering policy questions on metadata only.
• It does not hold credentials in escrow — the holder controls presentation.
• It does not touch payment instruments or hold funds — even where the web gate governs a purchase or trade, the authorization gates the merchant checkout's own submit (fill-less); where a store requires typing a card, the card lives only in a local vault on the operator's machine and never reaches Eniyan or the model.
• It does not modify or replace your entitlement / authorization policy.
• It does not host the agent runtime or intercept the agent's actions. Runtime telemetry, where you enable it, is self-reported by your agent and metadata-only — tool names, scopes, token counts, and outcomes; never tool inputs, outputs, or prompts.
• The one place Eniyan stores prose about an agent is Testing & QA, and only because your people type it there: when an operator documents a test, the prompt they used, the expected result and the actual result are kept so the record is real evidence. Nothing observes or transmits it. It is kept only after an admin confirms, is refused if it contains card- or social-security-shaped numbers, is removed automatically on a retention period you set, and is fingerprinted so the record stays provable after removal.
• It does not make access decisions on your behalf — it attests identity and scope; you decide.

Looking for the deeper architecture walkthrough for a security review? Contact your Eniyan account team.