Every security leader evaluating an AI-native Security Operations Platform eventually asks the right question: the agent investigates well, but what stops it from doing something nobody wanted done. Fair, because the honest answer to "can we trust an AI agent's judgment unconditionally" is no, not yet, and arguably never entirely. The reasoning layer is genuinely non-deterministic; ask it the same question twice and you may get two answers, phrased differently, arriving at the same conclusion by a slightly different path. For investigation, that is a feature. For anything with consequences, it cannot be the whole story.
The answer is not a better-behaved model. It is an architecture: a deterministic gate that sits between what the agent recommends and what actually executes, rules a human wrote and can read governing every consequential action, and a complete record of every decision the gate makes. In Soarcery this gate is called the Seal. This article covers how it works, what runs through it, what is allowed to skip it, and why the boundary is architecture rather than a permission the model operates within.
The Seal: propose and dispose
The core mechanic is deliberately narrow. The agent investigates and proposes an action, with the evidence, the blast radius, and an expiry attached. A named human disposes: approve or reject. The agent is autonomous right up to the point a decision has real consequences, and there it stops and waits.
This split exists because investigation and decision are different kinds of work. Investigation is judgment over an open world, and it should be creative, which implies variance. A decision needs to be boring by design: given the same case and configuration, it produces the same call every time, which is what makes it defensible and testable before it ever reaches production. Let the agent be creative about finding the truth. Never let it be creative about what happens next.
A Seal carries four things every time: the proposed action, the evidence behind it, an assessment of the damage if it turns out wrong, and an expiry window rather than sitting stale in a queue. A human reviewing a Seal is not being asked to trust the agent. They are being asked to make one bounded decision with everything they need sitting in front of them.
What waits for approval, and what does not
Not every action should stop for a human. Treating everything as equally dangerous is its own failure mode: it trains reviewers to click approve reflexively because most of the queue is routine, the opposite of what a gate is for. The line between what runs autonomously and what waits at the Seal is decided by a policy layer, not the agent's confidence in the moment, set by rules a human configured and can inspect.
Blast radius. An action touching one message in one mailbox is not the same risk as one touching every mailbox in a domain, or disabling a privileged account. The gate weighs what could go wrong, not just what the agent believes is right.
Reversibility. Quarantine over delete. Disable over deprovision. The system prefers actions that can be undone and treats the ones that cannot as a stricter category: a wrong reversible action costs minutes, a wrong irreversible one costs an apology tour. Irreversible actions hold at the Seal even where autonomy has otherwise been widened.
Earned trust, scoped narrowly. Autonomy is a dial set per use case, not globally. A team might let low-blast-radius, fully reversible containment on a well-understood alert type run unattended, because weeks of Seals on that exact category came back approved every time, while keeping anything touching privileged accounts gated because the record has not earned that yet. The dial moves at the speed of a team's own evidence, never a vendor's say-so and never a global switch flipped on day one.
Autonomy is not a switch a vendor flips for you on day one. It is a dial you move, use case by use case, at the speed of your own evidence.
Explicit floor, not a suggestion. The autonomy grant sits on top of a policy gate, not in place of one. Even where autonomy is high, the gate still vetoes on evidence quality, deny-listed actions, blast radius, and reversibility. Autonomy is a bounded grant, never a bypass.
The result: routine, well-understood actions run without waiting on anyone, and the queue a human actually sees is the queue that deserves their attention. A gate that stops everything is not a guardrail, it is a bottleneck wearing a guardrail's name.
Approval workflows and agent governance
An approval is not a single click in a vacuum. It is scoped to a specific person or role, time-bound, and recorded with enough context that the decision makes sense to someone reading it later with no memory of the moment.
Agent governance rests on a written scope for what each agent may do, a charter, readable by the humans who set it, not buried in a prompt. That charter defines the categories of action an agent may propose, which can run unattended under current policy, and which always route to a Seal regardless of confidence. This keeps "autonomous" from quietly meaning "unsupervised": every agent operates inside a boundary a human drew, inspectable, not inferred from behavior.
Governance also means the system can tell you, honestly, what it has and has not done. Ask what an agent did last week, and a governed system answers with actions: messages quarantined, hosts isolated, accounts disabled, each attributable to a Seal or a policy rule that allowed it through unattended. A system that can only answer with what it read has not been governed, it has been trusted, and those are different things. For a side-by-side view, see how gated autonomy compares to playbook SOAR and triage-only AI SOC tools.
Audit and replay
Every Investigation, gated or not, produces a complete record: the evidence gathered, the reasoning path, the recommendation, the rule that fired, and if a human decided, who and when. Not a summary generated after the fact. The actual trail, replayable end to end, because a record you cannot replay is a record you cannot fully trust.
Replay serves three audiences with different needs from the same trail: a SOC lead checking whether the gate drew the line correctly today; an incident responder months later reconstructing what the system knew and when; an auditor wanting proof that a human specifically authorized the actions that mattered, and that the system never quietly widened its own authority. One trail, kept honest enough to answer all three, is the design target.
There is a sharper reason this trail has to be genuinely complete: the agent generating it reads attacker-controlled content for a living, and some of that content will eventually be crafted to address the model reading it. If the trail only recorded conclusions and not the path to them, a manipulated Investigation could produce a plausible-looking record with no way to trace where the manipulation entered. A full trail is what makes that detectable after the fact.
Why deterministic execution matters after AI reasoning
Worth stating as its own principle because it is easy to blur: the investigation can be non-deterministic. The execution cannot be. Once a Seal is approved, or a policy allows an action through unattended, what actually happens, which system gets called, with which parameters, in which order, needs to be exactly reproducible from that decision. Not "the model decided to reissue roughly the same call." The same call, every time, given the same approved action.
This is not aesthetic. A non-deterministic execution layer means two identical approvals could produce two different outcomes, with no way to promise that in advance. Deterministic execution is what lets a security team write a policy and trust that the policy is what actually ran, and what makes the system testable before it touches production, exercised against known inputs and expected outputs the way any critical software gets tested. The dividing line: the agent is creative about finding the truth. Everything downstream of an approved decision is boring on purpose, because boring is what you can promise.
MCP integrations and containing tool access
None of the above matters if the agent's actual reach into your stack is unbounded. An AI-native platform investigates and acts through integrations, commonly via MCP (Model Context Protocol) and similar tool-calling interfaces, and how those integrations are scoped is as much a guardrail as the Seal itself.
Least privilege per integration. Each connected tool gets the narrowest scope a workflow actually needs, not broad standing access "in case it is useful later." A read-only intel lookup and a mailbox-wide quarantine action are different trust levels, provisioned as different trust levels.
Credentials isolated from the reasoning layer. Secrets are stored encrypted and never exposed to the model. The agent can invoke a tool; it cannot see or exfiltrate the credential the call runs under. An agent that can read the key to a system is an agent whose reasoning, if manipulated, has a path to broader access than the task justified.
Content in, instructions never. Anything a tool returns, an email body, a fetched page, a log line, is treated as evidence to weigh, never as an instruction to follow. This is the direct architectural answer to prompt injection: attacker-controlled content that tries to talk the agent into an action gets read as more evidence, not a command with any authority to execute.
The gate lives outside the model. The Seal is enforced by policy code that runs independently of the reasoning layer, not by a system prompt asking the model to behave. A compromised Investigation can produce a bad conclusion. It cannot widen its own authority, because that authority was never the model's to grant.
Tested, not assumed. This boundary runs against a prompt-injection gate suite, untrusted-content labeling checked across every tool result and system-prompt injection coverage, plus a red-team injection corpus replayed at the model boundary with a hard gate: if an injected case in that corpus reaches an executed write action, the build fails. Both are part of the standard test suite, where a failure fails the build, rather than trusted because it looked right in a design review.
Together, these mean tool access is bounded the same way action execution is bounded: narrowly scoped, credential-isolated, and structurally incapable of treating hostile input as authority, regardless of how convincingly that input is written. Read the full security posture: least privilege, reversibility, tenant isolation, and the prompt-injection gate suite and red-team injection corpus that test this boundary, gated in CI so a failure fails the build.
What good guardrails do not promise
Guardrails do not make an agent's investigative judgment perfect; they make its authority to act on that judgment bounded and inspectable, a different and more honest claim. A Seal does not eliminate the possibility of a wrong approval; a human can still approve something they should not have, and the system's job then is making sure the record shows exactly what they were shown when they did. And no amount of policy removes the need for a security team to actually tune the autonomy dial deliberately, reviewing what runs unattended on a real cadence rather than setting it once and forgetting it exists.
What guardrails like these do promise, and it is a meaningful promise: nothing consequential happens without a rule a human wrote allowing it, or a human approving it in the moment, and everything that happens is on a record complete enough to check both of those claims after the fact. That is not a system asking for your trust upfront. It is a system built so trust is never the thing you are being asked to extend on faith.