The control plane for agent actions.
SilentAuth is where sensitive automation asks for permission before it acts. Create projects, register agents, apply policy, review approvals, coordinate local proof, and issue receipts the agent must verify.
Control loop
Request, decide, verify
How it works
One authorization loop for every protected action
The control plane keeps the workflow concrete: a project, an agent, an intent, a policy decision, a proof tier, a receipt, and an audit record.
Create the project
The project owns API keys, policy defaults, registered agents, reviewers, and audit history.
Register the agent
Each automation gets a scoped identity before it can submit protected actions.
Declare the intent
The agent sends the exact action, parameters, risk tier, and requested proof before execution.
Resolve policy
SilentAuth routes the request to auto-approve, deny, reviewer approval, quorum, or local proof.
Issue the receipt
The response includes Receipt V2 claims bound to params_hash, policy_hash, proof_tier, kid, and expiry.
Verify before action
Your agent or gateway verifies the receipt. SilentAuth coordinates approval, it does not execute the action.
What the control plane owns
What stays outside it
FAQ
Control plane questions
The best user experience is simple: create an account, create a project, register an agent, submit a request, approve it, verify the receipt, then inspect the audit trail.
What is the SilentAuth control plane?
It is the hosted dashboard and API where teams create projects, register agents, define policy, review approval requests, issue receipts, and inspect audit history.
Does SilentAuth execute the protected action?
No. The agent, application, or gateway executes only after it verifies the receipt for the exact action and parameters. The control plane coordinates authorization.
Where does VINAC-FM fit?
VINAC-FM is a local proof layer for high-risk actions. The control plane records the requested proof tier and gateway state, while the local gateway performs the physical-presence proof.
Why separate the signer later?
The first hosted version can run on one VPS, but receipt signing should become an isolated private service with kid rotation and no public ports before serious production use.
How do QR codes and NFC cards fit later?
They should appear as proof tiers beside VINAC-FM. A receipt should say which proof tier was used so downstream systems can decide how much trust to give it.
Can this work offline?
The online control plane comes first. Later, a trusted local gateway can cache policy bundles, issue scoped offline receipts, and reconcile audit history when it reconnects.