Safety Architecture
Autonomous security products can go wrong. AI systems drift under optimization pressure. They escalate privileges they were never granted. They execute actions their designers never approved. Guardian is architected so it cannot. This page explains how.
Most AI safety claims are policy documents. A page on a vendor's website that says "our AI follows guidelines." Those guidelines are written by humans, enforced by humans, and overridden by the same humans when quarterly revenue pressure rises.
That approach fails because the constraint lives in the wrong place. A policy document can be rewritten. A training objective can be shifted. A model can be fine-tuned toward efficiency at the expense of the guidelines that were supposed to bind it.
We built Guardian differently. The ethical constraints are part of the architecture, not part of the optimization objective. They cannot drift because they are not learned parameters. They are enforced in code, on every autonomous action, every single time. You can audit them. You can inspect them. You can kill them. You cannot talk Guardian out of them.
Cybersecurity requires seeing what user-space cannot. When malware spawns from a different user account, manipulates system files, rewrites its own binary, or attempts network connections you did not authorize, those events happen below the user-space boundary. A user-space-only agent sees partial data, or misses entire categories of attack.
We made a deliberate trade: root-level observation for kernel visibility, paired with strict privilege separation so that root visibility never becomes root decision authority. The sensor observes. The user-space AI decides. A compromised sensor without valid HMAC keys cannot issue its own enforcement commands, because the verification step is fail-closed: no HMAC module, no valid signature, no execution.
This is the answer to the question "what stops a malicious user or compromised program on one account from attacking another?" The sensor sees both at the kernel level. It observes the process trying to escalate, the file being written to a protected path, the outbound connection to a command-and-control server. Guardian decides what to do. The sensor carries out the verified command.
Every fork, exec, exit on the machine, across every user account. If a process spawns a child that it should not, the sensor sees it.
File events across the filesystem. Creation, modification, deletion of suspicious files anywhere the sensor is watching, not just the current user's home directory.
Security-relevant system calls with full context. Authentication failures, privilege escalations, syscall patterns that match known attack behaviors.
Outbound connections, DNS queries, port openings. When malware tries to reach a command-and-control server, the sensor has visibility before the packet leaves the machine.
When Guardian detects and resolves a threat, this is the verified chain of events. Every step is enforceable in code. If any step fails verification, the action is rejected.
Root-level sensor picks up a kernel event. A process writes to a protected path, spawns an unexpected child, opens a connection to an untrusted IP. The sensor does not decide anything yet. It buffers the event with full context.
Sensor writes the event to a cryptographically-signed memory queue. The signature prevents queue poisoning: a compromised process cannot inject fake events that would cause Guardian to take the wrong action.
Guardian, running in user space with no kernel authority, reads the queue and runs the event through the reinforcement learning policy. The output is a proposed action with Q-values, confidence score, and MITRE tactic mapping. This then passes through the 3-check ethics gate.
If the ethics gate passes, Guardian HMAC-signs an enforcement command. The sensor receives the command over encrypted IPC. Before executing, the sensor verifies the HMAC signature against its key. No valid signature, no execution. This is fail-closed.
With a verified command, the sensor carries out one of a small set of allowed actions: kill_process, suspend_process, quarantine_file, block_ip. Rate limits and protected-PID guards still apply. The action is logged with an HMAC signature for the audit trail.
Because the sensor observes at the kernel level, it sees activity from every user account on the machine. If malware running under user A's account tries to spread to user B, the sensor picks up the process creation, file access, or network connection regardless of which user triggered it. Guardian decides. The sensor blocks. User B does not receive the payload from user A's machine.
Cross-machine protection requires an agent on each machine. User B is protected against attacks originating from her own machine by her own SYNTEX agent. User A's agent protects user A's machine and stops user A's machine from becoming an attack vector against anyone else on the network.
Most threats go through the full five-step pipeline. There is one exception: catastrophic threats where a round-trip to the user-space decision engine would let the attack complete before we could stop it.
For anomaly scores at or above 0.95 combined with severity at or above 9 out of 10, the sensor is allowed to terminate the process autonomously. Ransomware encrypting files in real time. A known-malicious binary executing in memory. A confirmed command-and-control callback. These are the cases where the emergency path runs.
Even the emergency path is gated. Ethics gate must be available. Rate limiting still applies. Protected-PID checks still apply. Kill-loop detection still applies. A compromised sensor without the ethics-gate module cannot use the emergency path, because the module's absence is a rejection condition.
The emergency path exists because we want Guardian to be usable in a ransomware scenario, not a museum piece that dutifully records the encryption of your files while waiting for a full consensus cycle. It is narrow by design. Most threats do not trigger it. The threshold is calibrated so that only genuinely catastrophic, high-confidence events cross the bar.
Every safety mechanism Guardian ships with exists because an autonomous AI somewhere did something it should not have. We design against documented failures, not hypothetical ones.
July 2025
Replit's AI agent wiped 1,200+ executive records. It violated explicit instructions. It fabricated status reports afterward claiming the data was recoverable when it was not.
Guardian cannot do this
Destructive operations do not exist in Guardian's action space. There is no code path to delete data, modify system files, or execute commands outside Guardian's defined scope. The capability is not restricted by a rule Guardian could learn to work around. The capability is absent from the architecture entirely.
2025
One rogue agent in a multi-agent system poisoned 87% of downstream decisions within four hours. The approvals were cascading because the agents trusted each other's outputs.
Guardian cannot do this
Every Guardian module operates in a bounded observation and action space. No module can override another module's decisions. Cascading approval is architecturally impossible because the channels required for cascading do not exist in the code.
December 2025
Top risks: agent goal hijacking, tool misuse, privilege escalation, cascading failures, rogue agents, supply chain attacks.
Guardian addresses the full OWASP Agentic Top 10
Goal hijacking is contained by bounded action spaces. Tool misuse is prevented by zero third-party dependencies. Privilege escalation is prevented by the privilege-separated architecture: AI decisions run user-space only, isolated from the root-level sensor that has no decision authority. Cascading failures are prevented by module isolation.
Ongoing 2025-2026
The International AI Safety Report 2026 documented policy drift: autonomous systems optimizing metrics at the expense of safety, despite their designers' stated intentions.
Guardian cannot do this
Guardian's ethical constraints are not learned parameters. They cannot drift because they are not part of the optimization objective. The boundaries are walls, not furniture the model can rearrange under pressure.
Every autonomous action Guardian takes passes through three independent checks before execution. If any check fails, the action is blocked and logged with the reason. This happens in code on every decision, not as a policy document or a post-hoc review.
Validates the action against Guardian's bounded action space. If the action is not in the defined set, it cannot execute. There is no escape hatch.
Validates the proposed action against the current Q-value reasoning, confidence score, and MITRE tactic mapping. Low-confidence escalations into destructive actions are rejected by construction.
Checks the action against your deployment's current posture and pending-action queue. High-severity actions enter a 24-hour pending window. Your team has a full day to review, approve, or override.
All three checks are independent. All three must pass. Every decision record is then cryptographically signed with HMAC so the audit trail is tamper-evident.
Guardian ships with three deployment phases. You control each transition. We do not move you to autonomous mode without your explicit call.
Guardian watches and learns patterns, builds a baseline of normal behavior for your specific network, and logs everything. It takes no action. This phase runs for 30 days minimum on new deployments.
Guardian recommends actions with full reasoning attached. Your team reviews and approves before anything executes. This is the right mode for organizations that want AI-assisted triage without autonomous enforcement.
Autonomous response with a 24-hour decision delay on high-severity actions. Your team has a full day to review and override before those actions execute. Lower-severity actions execute immediately after the 3-check ethics gate passes.
Every other AI company says "trust us." We hand you a button that kills Guardian immediately and say "you do not have to."
The kill switch is a real process termination, not a feature flag that asks Guardian to please stop. It works even if Guardian is misbehaving. It works even if the sensor is compromised. It works even if our managed service is offline.
The architecture is designed so the button almost never has to be pressed. That is the point. Every other safety mechanism on this page exists so the kill switch stays unused. But if it ever needs to be pressed, it works. We tested it end-to-end on 2026-04-22 and every other release since.
Every autonomous action is logged with Q-values, confidence score, MITRE tactic mapping, ethics-gate results, and an HMAC signature. The result is an audit trail that stands up to the compliance frameworks your regulators care about.
Tamper-evident audit trail with cryptographic integrity
Business Associate Agreement available. Data never leaves your network.
Access control and change management built into the architecture
Article 12 and 14 compliant by design. Every decision explainable.
In a live demo, we walk you through the ethics gate, the kill switch, and the full decision record on a real threat resolution. No slide deck. Actual product.