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, eniyan-mail, eniyan-a2a) are an explicit opt-in that runs on YOUR machines: the gate asks Eniyan policy questions and the cloud answers with decisions — metadata in (root and folder aliases, domains, hashes), decisions out; content never crosses the wire, and the cloud never becomes the executor.

PACH 1 (personal) accounts can also run eniyan-scan, a local discovery tool for macOS, Linux and Windows. It is not a gate: it asks no policy questions, receives no decisions, and is never in the path of anything an agent does. It reads the MCP configuration of the AI coding tools on the machine, looks in the projects that Claude Code, Codex, Gemini CLI, VS Code and Cursor record in their own settings files for agent-framework dependencies and agent configuration files, and reads the person's own background job definitions, then reports a metadata-only inventory. Each finding carries its kind (an MCP server, an agent framework, an AI coding tool, or an always-on agent runtime), its name, which tool's configuration it came from, its transport, the name of the program that launches it, its package name when that is a well-known one, which well-known dependencies matched, a remote server's hostname when it looks public (never an IP address or a name under a well-known local-network suffix), whether the tool has it switched off, how strong the match is, and a salted hash in place of each project folder or job label (or, for a server set up for the whole user account, of the computer itself); each report adds only the device's own token, the scanner's version, the corpus version, what started the run, and when. File contents, paths, usernames, command arguments, environment variables, headers and full URLs never leave the machine. The inventory is visibility only: the person approves each finding or marks it not allowed in the dashboard, and neither decision blocks anything. The one automatic approval is for a server an Eniyan gate launches on the machine itself, never a remote one; the gate is recognized by the launching program's name, which the cloud cannot verify, and the approval grants nothing. An approval covers what a server runs, so the same name running something else comes back as a new finding. It runs only when invoked until the person explicitly installs its background jobs, which use the operating system's own per-user scheduler, and one command removes them. EACH 1 (team) accounts cannot enable it.

eniyan-scan also reports what those agents can reach, from configuration files alone: each AI coding tool's saved permission settings, the files where developer command-line tools keep their sign-ins, and the CI workflow files in those same projects. It never runs a sign-in or status command, never invokes a credential helper, never evaluates a CI expression or fetches a remote include, and never opens a private key (a key file counts by its existence). What it sends for these findings is closed-set identifiers from a list Eniyan publishes to the scanner (which tool, which service, which kind of permission, how a credential is stored), the public hostname a sign-in authenticates to, and a salted hash for a project or CI job (and, for settings and sign-ins that apply to the whole user account, for the computer itself, so each computer is shown on its own), plus a CI action's owner and name only when it is a well-known one. It never sends a token or any part of one (not its length, a prefix or a hash: presence is a yes or no), the text of a permission rule, command words it does not recognize, environment variable or secret names or values, usernames, account or profile names, email addresses, file paths, workflow, job, branch or repository names, SSH host aliases, or IP addresses. An approval covers exactly what the dashboard showed the person: if the finding changed while the page was open, the approval is refused and nothing is recorded. It keeps covering only that: if a later report shows the finding can do more (an MCP server whose tools stopped asking first, for one), it asks again instead of staying approved.

Credential lifecycle

Issuance — after a verified session, Eniyan signs a W3C Verifiable Credential (ES256 JWT) describing the subject, trust level, and scope.
Presentation — the holder (or your platform) presents the credential token to a verifier.
Verification — the verifier checks the signature and, for authoritative checks, calls Eniyan for live revocation state.
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, web, email and agent-to-agent gates are explicit opt-ins that run on your own machines, with Eniyan answering policy questions on metadata only. The local discovery tool, eniyan-scan, is not a gate and is never in that path.
It does not install background software on its own. Installing the SDK starts nothing; on a PACH 1 account, eniyan-scan's background jobs exist only after an explicit install, never change a configuration file, never run a sign-in command, report only the metadata listed under Trust boundaries, and are removed by one command.
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.