every agent acts on a sealed mandate.

who the agent acts for and what it may do, granted once, sealed, and signed. every action chains back to the mandate that allowed it.

the problem

most agents run on standing credentials. the scope of what they may do lives in a config file, a ticket, or someone’s memory. when an agent does something wrong, nobody can produce the authority it was acting on, because the authority was never a thing you could hold.

syenmakes the mandate a thing. it is sealed and signed with ed25519 at grant time, chained with sha-256 to every action taken under it, and anchored daily to digicert’s rfc 3161 trusted timestamp authority.

how a mandate works
  1. 01grant

    a person or system grants the agent a scope: who it acts for, what it may do, where that ends.

  2. 02seal

    the mandate is sealed and signed before the agent moves. authority exists as proof, not config.

  3. 03chain

    every action the agent takes chains to the mandate that allowed it.

where it holds
before it acts

the mandate is already sealed. there is no act first, authorize later.

while it acts

each action verifies against the mandate in real time.

when it drifts

an action outside the mandate fails verification against it.

when it ends

a revoked mandate stops verifying. the agent is done, provably.

independent verification

proof that stands on its own.

anyone checking the mandate or the actions under it does it with openssl. no access to your systems. no access to ours.

ed25519 signatures·sha-256 chain·rfc 3161 anchoring·openssl verification
where teams use it

teams that need to know their agents, issue each one an agent passport, and keep the audit trail that proves what happened under each mandate. see the governed workflows on the use cases page.