Autonomous response
Zynth Auth detects security signals — a replayed refresh token, someone probing a password from inside a live session. Autonomous response is the tier above detection: the platform can act on one of those signals, ending the compromised sessions in seconds instead of whenever an operator next reads the queue.
It ships off, and it does not turn itself on. This page is the model behind that: what it may do, what it may never do, and how a response class earns the right to act unattended.
The one-line version. Autonomy is earned statistically, per organization, and revoked by a single reversal. There is no setting that makes the platform act on your organization without your own people first approving that exact kind of action, repeatedly, over time, with a clean record — and one undo takes it away for thirty days even when every other criterion is still met. You can always make it stricter; you cannot buy your way past the evidence. We have run the whole cycle on our own production and published the numbers: see Proven on our own production.
The starting position
Three independent things must be true before anything happens automatically:
- The deployment enables execution. On a self-hosted install this is
AUTONOMY_EXECUTION_ENABLED, off by default. Until an operator sets it, the engine runs in shadow — it records what it would have done and does none of it. - Your organization raises a level. Every organization starts at Manual for every response class. A fresh tenant acts on nothing.
- The class has earned it. Acting without a human additionally requires clearing the graduation gate below.
Skip any one of the three and the engine is an observer with a very good memory.
The four levels
A level is set per response class (below), not once for the whole organization.
| Level | What happens when a signal fires |
|---|---|
| Manual | Nothing acts. The decision is recorded as shadow — what we would have done. The default. |
| Recommend | A proposal is raised and waits for a person. Nothing changes until someone approves it. |
| Graduated | Acts unattended only where the class has cleared the gate; everything else still proposes. |
| Full | Acts within the guardrails and notifies. Never silent. |
Choosing a weaker level than you are entitled to is always honoured — a good track record never overrides your setting. The ladder only ever describes a ceiling.
Blast-radius classes
Responses are classed by who is harmed if the signal that triggered them was wrong — not by how severe the threat was. That ordering is the whole safety argument, so the ceiling on each class is fixed in code and configuration can only tighten it:
| Class | What it does | If the signal was wrong… | Ceiling |
|---|---|---|---|
| Contain source | Slows or blocks a source | The attacker is inconvenienced; a legitimate user sees slowness | Full |
| Stop an AI agent | Stops one AI agent, reversibly | No person is affected. The agent's automation pauses until a human releases it — one call | Graduated |
| Raise assurance | Demands another factor | The user does one extra step | Full |
| Revoke access | Ends the user's sessions | The user is signed out and signs back in | Graduated |
| Disable principal | Locks the account | The user is locked out until an admin acts | Recommend |
Disable principal can never run unattended, at any level, however good the record — a machine cannot undo it, so a human signs every one. That is a deliberate refusal of "all levels available for everything".
"Stop an AI agent" is its own class, and deliberately not "disable principal". Suspending
a person's account is capped at Recommend because a machine cannot undo it and a locked-out
human is a real harm. Stopping a non-human principal is a different act: it affects nobody's
access to their own account, it is a single reversible switch, and any administrator holding
agents:kill releases it immediately. Its ceiling is Graduated — the same evidence every
other unattended class must earn — never Full, because a stopped agent is still a customer's
automation halting mid-run.
The response layer may contain an agent; it may never grant one anything. The class's vocabulary is closed to reversible containment in code: an action that could widen an agent's authority cannot be registered at all, and undoing a containment — which hands authority back — is refused to any non-human caller, exactly as releasing a kill switch by hand is.
What exists today. Two levers are implemented: revoke sessions (end every session for one user, on every device, immediately — the user can sign in again straight away), a revoke access action; and stop an AI agent (kill switch on, every issued token dead), a stop an AI agent action. The remaining classes have ceilings defined but no lever behind them yet. Neither agent detection nor an agent playbook is wired to the agent lever yet, so today it is reachable only through an operator's own approval, not from a detection.
The inducibility cap
A signal an attacker can deliberately trip is a signal they can aim. Any detection judged attacker-inducible is capped at Recommend regardless of its class or its record — wiring it to automatic enforcement would hand an outsider the trigger. That judgement is written down per detection at review time rather than inferred from how precise the rule is: a signal can be both highly precise and trivially spoofable.
What the platform will respond to
The mapping from detection to response is a reviewed table in code, not a model's opinion. The same detection and the same catalogue version always produce the same plan, which is what makes a decision explainable months later. Today:
| Detection | Response | Why this response |
|---|---|---|
| Refresh-token reuse | Revoke the user's sessions | A rotated refresh token replayed is the strongest token-theft signal we have, and the thief holds a credential from that family. Ending the sessions removes the attacker's access and costs the legitimate user one sign-in. |
| Password-change probing | Revoke the user's sessions | Repeated wrong current-password inside an already-authenticated session is someone sitting in a stolen session hunting for the password. Revoking evicts exactly them. |
Both responses point at the attacker's access, not the victim's account. The failure this guards against is reflexive escalation — "the user is under attack, so lock the user" — which harms the person who did nothing wrong.
Graduation: the evidence a class must earn
A class rises above Recommend only when your people, adjudicating this engine's proposals on your traffic, have produced enough evidence. Three criteria, all required:
- Confidence. The statistical lower bound of the class's approval rate must clear a bar (95% confidence interval). A bound, not a raw count — a count measures how big you are, not how good the engine is, so a perfect record needs fewer samples and any denial demands more.
- Temporal coverage. The adjudication record must span at least 14 days — a fortnight covers weekends, month-end, and a full on-call rotation, which no sample count guarantees.
- A clean reversal window. Any reversal in the trailing 30 days demotes the class and restarts the window. Undoing an action is the signal the engine got something wrong, and it is treated as one.
Both numbers are floors. The bars and the minimum span are operator-only settings that can be raised but never lowered, so there is no configuration that shortens the wait.
Evidence is scoped to the version of the response catalogue that produced it. Change what the engine decides and the track record resets — a record is evidence about a specific decision procedure, and it does not survive that procedure changing. (Editing the rationale prose deliberately does not reset anything; the behaviour is unchanged.)
A denial costs more than an approval gains. Because the bar is a bound rather than a rate, one denial both lowers the observed rate and adds a sample, while the clean streak that undoes it is long — near the bar the whole margin is a single adjudication wide. On our own production soak, a class sitting one adjudication over a 0.95 bar would have needed ~32 consecutive clean approvals to recover from one "no". That is a real property of the gate, not a rough edge: an engine whose track record could be repaired cheaply would not be evidence of anything. Each class therefore reports the cost of its next denial alongside its current standing, so the trade-off is visible before the decision rather than discovered after it.
You can read exactly where you stand at any time, per class, including how many more clean approvals it would take and what one denial would cost — see Operating autonomous response.
The hard stops
These apply at every level, including Full, and none of them can be configured away:
- The engine never acts on someone who could stop it. Owners, and anyone holding the permissions that disable or reconfigure the engine, are never targets. An engine that can lock out its own off-switch has no off-switch.
- Blast-radius caps. Two budgets per class, checked before acting: executions per hour, and — the one that matters — distinct principals affected per 24 hours. A hundred actions against one compromised account is incident response; ten against ten different people is the engine going wrong, and only the second limit can tell them apart. Hitting either halts that class and raises a critical detection.
- Approving is bounded by your own authority. You cannot approve an action you could not perform yourself, and the same rule governs undoing one.
- The world is re-checked between the yes and the act. A proposal carries a fingerprint of the exact effect that was approved; if the situation has moved, it expires rather than acting on facts that have aged out.
- An emergency stop, always available. Disabling autonomy is time-bounded by default so it re-arms itself — the real-world failure is the switch nobody turns back on. Every change to it raises a critical detection, because disabling the engine is both a legitimate emergency action and the first thing an intruder with an admin session would do.
- Nothing unattended is silent. An action taken with no human in the loop notifies on your alert channels, naming the effect, the decision, and the off-switch.
Proven on our own production
We do not ask you to take the gate on trust. We ran it against our own production platform for fifteen days and recorded what happened, including the part that is inconvenient for us.
The soak (2026-08-07 → 2026-08-21). A disposable organization, one test account, and a real security signal — a refresh token replayed after rotation — driven roughly six times a day on a schedule. Every approval went through the same detector, planner, executor and approval endpoint your organization would use. Nothing was written into the evidence store by hand.
| result | the bar | |
|---|---|---|
| Clean adjudications | 90 of 90, zero denials | 73 |
| Statistical confidence (Wilson lower bound, 95% CI) | 0.9591 | 0.95 |
| Calendar span | 14.43 days | 14 days |
| Reversals during the soak | 0 | 0 |
| Platform deployments mid-soak | 11+, none disturbed the loop | — |
Then the part that matters. With the gate reporting eligible, we raised the class and let one more signal arrive. The platform ended the compromised sessions on its own, one second after the detection, with no human involved — and the "autonomy acted" notification landed on the configured channel, which is the path that only fires when nobody approved.
We then undid it, deliberately, to test the safety net rather than the capability. The gate's next answer:
90 of 90 · confidence 0.9591 · span 14.43 days — every earning criterion still met — and
eligible: false.
One reversal outranks ninety perfect approvals, and the class stays down for thirty days while the record rebuilds. That is the property worth checking in any vendor that claims autonomous response: not whether it can act, but what it costs to make it stop.
What this evidence is, and is not
Be precise about what a run like this demonstrates. Those ninety approvals came from an operator-held credential on a schedule. Each was a real verdict recorded through the real endpoint — none of it is fabricated — but it is not a team exercising judgement over fifteen days either. It is evidence about the mechanism, not about anyone's oversight process. Your own graduation would be evidence about yours, which is the entire point of making the gate per-tenant rather than shipping a certificate that says we tested it.
Two honest limits the run also exposed, both recorded in our decision record rather than smoothed over: Graduated may be out of reach for an organization whose incident signals are genuinely rare — the gate wants 73+ adjudicated proposals inside a fortnight, and a quiet tenant may never accumulate them — and temporal coverage measures a span, not a distribution, so it cannot by itself distinguish a fortnight of steady operation from a burst plus one late decision. Recommend, where the platform proposes and you decide, is the level we expect most organizations to sit at, and it is a complete product on its own.
Undo what the agent did
Stopping an agent — a kill switch, an automatic freeze — ends what it will do. It says nothing about what it already wrote. So containment is only half of a real recovery, and Zynth keeps the other half: a per-agent action journal records the changes an agent made, each with the state it would restore to, and an operator can roll the agent back.
Rollback is honest about what it can and cannot do. It undoes a change by making a new, recorded change that puts the prior state back — never a blind delete — and it reports the result in three groups: what it restored, what it skipped (because a person had already corrected that resource since, and the platform will not silently discard your fix), and what was irreversible (a change with no clean inverse — a public artifact whose bytes live in another system, say — surfaced with the reason rather than pretended away). A partial rollback that tells you exactly which third it could not undo is worth more than a false "all clear". Reversing an agent's writes is an operator action a person performs (the same rule that makes releasing a kill switch human-only), and every rollback is written to the audit log.
Everything is on the record
Every decision — including the ones where the engine declined to act, and why — is a row in a ledger you can read, and every action, approval, denial and reversal is written to the tamper-evident audit log. That trail is what makes this reviewable rather than merely fast: it is the human-oversight evidence for EU AI Act Article 14, ISO/IEC 42001, and SOC 2 CC7.3.
Unadjudicated shadow rows age out on a retention window. Anything a human decided, or the engine acted on, is kept — deleting it would destroy the account of what the platform did.
Next
- Operating autonomous response — turn it on, set levels, approve, undo, stop.
- Human-in-the-loop agent approvals — the same oversight idea applied to AI agents acting in your organization, rather than to the platform itself.
- Tokens & sessions — what "revoke sessions" actually does to a user.