Organization governance
Governance is the organization-level counterpart to per-agent autonomy. It sets rules that apply to every agent in the organization, on top of each agent’s own settings — and, if you want, hands some decisions to a service you run yourself.
Find it in Console → Settings → Governance. Owners and admins can see it; only the organization owner can change it.
Minimum approval level
Section titled “Minimum approval level”The minimum approval level is the least cautious any agent here may be.
An agent set looser than the minimum is raised to it. An agent set stricter keeps its own, stricter setting — the floor is a floor, not a target. Set it to Supervised and nobody can quietly put an agent on Autopilot.
Leave it at no minimum and each agent decides for itself, which is the default.
Organization approval rules
Section titled “Organization approval rules”The same always allow / must ask / never rules you can set on a single agent, applied to every agent in the organization. Rules are written by action — send_email, bash:git push*, mcp:linear/*.
“Never” wins over everything an individual agent allows. It is the one control that cannot be worked around from inside an agent’s own settings, which is what makes it the right place for something your company simply doesn’t do.
Always confirm payments and credentials
Section titled “Always confirm payments and credentials”Every organization starts with a final confirmation on spending money and handling secrets, regardless of any agent’s autonomy level or rules. This is the safety floor, and it is on by default.
Notifying your own systems
Section titled “Notifying your own systems”If your organization needs to apply a policy that lives in your own systems — a data-classification check, a change-freeze window, your own audit trail — you can have Auteryn call an HTTPS endpoint you run at key moments in a run, and let it have a say.
Limited availability. Because each call carries a signing secret to a server outside Auteryn, policy endpoints are enabled for a small set of organisations Auteryn operates itself for now. The rest of this page applies once your organisation is included.
When it gets called, and what it can do
Section titled “When it gets called, and what it can do”| Moment | What your service can do |
|---|---|
| A run starts | Nothing — informational, for your own logging |
| Someone sends a message | Block it with a reason, or add context the agent must take into account |
| Before an action that needs approval | Approve or refuse it, in place of a person |
| A run finishes | Ask for one more pass, with an instruction |
| A helper finishes | Nothing — informational |
| A long conversation is about to be condensed | Say what must be preserved in the summary |
Pick the moments you care about per endpoint; you don’t have to take all of them.
When your service blocks a message, the conversation says so plainly — Blocked by your organization’s policy: {your reason} — so the person isn’t left guessing. When it adds context, that text reaches the agent as your organization’s policy for that run. When it asks for another pass, that pass is an ordinary, billed, visible run that shows up in the conversation like any other, capped at three per conversation per day, and never after someone has cancelled.
Setting one up
Section titled “Setting one up”Each entry takes an address, a signing secret, the moments to call it for, and how it should behave when it fails:
- Address — an
https://URL that is publicly reachable. Private, internal and loopback addresses are rejected when you save: a call Auteryn can’t safely make is one it won’t make. - Signing secret — at least 16 characters. It’s stored encrypted and never shown again, so keep your own copy.
- Every request is signed, so your endpoint can prove it came from Auteryn. The signature and its timestamp arrive as the
X-AgentForge-SignatureandX-AgentForge-Timestampheaders (the header names carry the product’s former name and are kept as-is so existing integrations never break); compute the same HMAC over the request body with your secret and compare. - Auteryn waits about two seconds for an answer.
Fail open, or fail closed
Section titled “Fail open, or fail closed”By default an endpoint fails open: if your service is slow, unreachable or errors, runs carry on as though it had answered. That’s the right default — an outage in your policy service shouldn’t stop your team working.
Turn on Stop the run if this can’t be reached to make a specific endpoint fail closed instead. Use it only where a missed check is worse than a stopped run.
Test before you rely on it
Section titled “Test before you rely on it”Test sends a real call and tells you what came back — Reachable · 240 ms, Refused, Timed out, or Couldn’t check. Always run it before switching an endpoint to fail-closed.
If you configured a policy endpoint before this page existed, it appears here marked Set up earlier, and stays editable where you originally set it.