Sigilant · Agent identity gateway
AI agents are already raising orders, changing records and moving money inside your systems, on keys nobody can trace to a person. Sigilant makes every agent act as itself, with permission, with proof.
Does this sound familiar?
Each one has an honest answer today, and it is not a good one. Sigilant exists so the answer becomes a record you can show.
The purchase order
Today: the agent used the integration's API key. The ERP logged the key. Ten agents share it, so the log cannot say which one, for whom, or whether anyone said yes.
With Sigilant: the order was over the limit, so it waited. A named person approved that exact order, and the record carries her signature.
The audit
Today: a spreadsheet, maybe. The government's security manual now expects an identity and a register for every agent, and APRA's CPS 230 holds you to the processes they run.
With Sigilant: every agent is registered with an accountable owner and a sponsor who re-confirms it. An agent nobody vouches for stops and waits for a person.
The rollout
Today: the safe answer is no, so the project stalls, or it goes ahead with a key in a config file and everyone hopes.
With Sigilant: the agent never holds a key. Sigilant supplies access for the one action it has approved, then takes it back. Security can say yes.
The purchase order is from our demo, not a customer. It is the run we show in a briefing.
What it costs you today
Who did it, on whose behalf, and who approved it. Three questions, no reliable answer.
Revoking a shared key stops every integration that uses it. So nobody pulls it until it is too late.
Agents arrive inside products, scripts and repositories. The ones you cannot see are the ones that bite.
Every agent the business wants is a risk you carry personally. Saying yes needs something to point to.
A real run
From our demo: a procurement agent, a person called Priya, and an ERP. Nothing in the agent or the ERP was rebuilt.
How it works
Agents call their tools through Sigilant instead of directly. Neither the agent nor the system behind it has to be rebuilt.
Step 01
Each action is checked against your policy before it runs: which agent, for whom, doing what.
Allow, hold or refuse
Step 02
Actions you mark as high-risk are held for a named person, who sees exactly what they are approving.
A person in the loop
Step 03
The agent never holds the keys to your systems. Access is supplied for the one action, then gone.
Nothing to steal
Step 04
Every decision, allowed or refused, is written to a record that shows if it has been altered.
Evidence as a by-product
What you can now say
Each one is a capability, written the way you will have to say it.
Find them first
Agents arrive inside products, scripts and repositories, and most organisations meet theirs in an incident. Sigilant looks first: a governed runner scans your repositories and probes your systems for agents, MCP servers and model keys, and reports each find for a person to claim or dismiss.
It keeps looking. Every pull request, every deployment and every 24 hours start a governed retest, so the answer to "are we still as we were" is a signed record, not a feeling.
Discovery and retesting run on the BugXHunter runner, governed by Sigilant like any other agent. Read-only probes go through on their own; anything that could change state waits for a person.
Deployment
People sign in and approve through the identity provider you already run, such as Okta, Auth0 or Microsoft Entra ID, and ownership of agents follows the people and groups you already manage. Sigilant runs in your environment: your policies, your records and the detail of what your agents do stay with you.
Sigilant is in early access. We are happy to walk through it against your own agents and systems.
We will show you what governing that path looks like, in your environment, against your policy. An hour, and you leave with the record.
Get in touch
Tell us which agents you are putting into production and what they need to reach. We will reply within one business day.
