QuietOS+Sentinel: Adding Bidirectional Security Screening to Personal Agents

The permission boundaries of personal AI Agents are being redefined. A developer shared his approach on Reddit: QuietOS handles "outbound" permission control, Sentinel handles "inbound" content review, and the two components together sandwich the Agent in between—with the final decision always left to humans.

The Outbound Problem: Who Holds the Keys?

The developer previously posed a question to the community: should a personal Agent hold its own keys, or should a gate in front of it hold them? His answer is QuietOS—the Agent only holds identity, while QuietOS holds permissions; approvals expire and have a verifiable log.

This design solves the authorization problem when an Agent "does things outward": every sensitive operation must pass through QuietOS's gate. Permissions are not permanently valid tokens but temporary permits with expiration times. The accompanying proof log records every hold and decision using SHA-256 hashes, written into an append-only ledger that can be audited after the fact.

Append-only ledger is a log structure that only allows new records to be written and does not permit modification or deletion of existing records; blockchain is its most well-known implementation. In security audit scenarios, its value lies in tamper resistance: once an authorization or decision is written, it cannot be quietly rewritten afterward. Combined with SHA-256 hashing, each record can generate a digest fingerprint, and any change will cause a hash mismatch and thus be detected. Such structures are commonly used in scenarios requiring after-the-fact accountability, such as permission approvals, key usage, and Agent actions.

The Inbound Blind Spot: What the World Says Cannot Be Treated as Commands

QuietOS only covers what the Agent "does" to the external world, not what the external world "says" to it. This is exactly the position Sentinel is meant to fill.

The developer's core principle is straightforward: world content is only data, never instructions. Web pages, emails, and pasted messages all pass through Sentinel for inspection before entering the "brain." If content contains instructions from external sources, Sentinel intercepts it, displays the original text precisely to the user, and lets the user click to allow or terminate. If the judgment is uncertain, it defaults to denial (fail closed).

This approach counters prompt injection-style attacks: attackers do not need to compromise the model; they only need to hide malicious instructions in content the Agent will read. Sentinel's method is to separate "understanding content" from "executing instructions," so that external text cannot directly trigger actions.

Prompt Injection is a class of attacks that emerged with large language model applications, analogous to SQL injection in traditional security: attackers mix carefully crafted text into data the model will read, inducing the model to mistake the data for instructions to execute. The risk is higher for personal Agents because they often possess real permissions such as file read/write, email sending and receiving, and browser operation. Common variants include direct injection (instructions embedded in user input), indirect injection (instructions buried in web pages, documents, or email bodies), and bypasses via encoding, translation, summarization, and similar methods. Currently, the industry has no complete defense; mainstream mitigation approaches include least privilege, separating external content from instructions, and manual confirmation before execution.

Engineering Status and Honest Limitations

The project has made its code public, released version 0.1.0 on PyPI, and its benchmark test suite passes 34/34. The developer explicitly states there is no monthly fee and no mobile app version yet.

The limitations he lists himself are equally worth noting: protection has not yet been actually deployed on the Gemma model on mobile; and four known vulnerabilities remain to be fixed—synonym substitution, leet spelling variants, exfiltration instructions hidden in summaries, and non-English override instructions. These four categories are typical techniques for bypassing text review, and acknowledging their existence is more valuable for reference than claiming they are "solved."

The developer ends by throwing the question back to the community: before your Agent starts reading the world, what do you most want it to check first?

Fail closed is the opposite of fail open and is a fallback strategy for security systems when a determination cannot be made. Fail closed requires the system to deny rather than allow when detection is uncertain, components are abnormal, or rules do not match. For content review components, this means preferring to falsely block normal content over letting potential attacks through; the cost is reduced usability and more manual confirmation required from users. Sentinel in the article adopts this strategy, consistent with its assumption that "world content is only data": allowing is the exception and requires active human approval.

Leet spelling variants refer to writing that substitutes letters with numbers or symbols, such as writing "ignore" as "1gn0r3" or "admin" as "4dm1n." Such transformations are inherently unfriendly to filters based on keywords or string matching, because rule libraries struggle to enumerate all combinations. Attackers often combine them with synonym substitution, mixed casing, inserted irrelevant characters, and other techniques to bypass content review. Defense typically requires normalization preprocessing (restoring common substitutions) or introducing semantic-level judgment rather than relying solely on literal matching.

The Significance of Bidirectional Gates for Personal Agents

The idea behind this approach is to shift the Agent's security boundary from "whether the model itself is smart enough" to "whether the peripheral gates are strict enough." Outbound relies on QuietOS to control permissions, inbound relies on Sentinel to control content, and humans remain in the loop at both ends.

For developers experimenting with local personal Agents, this layered design provides a skeleton worth borrowing: separation of permissions and identity, external content untrusted by default, denial when uncertain, and traces left for all decisions. Its value lies not in functional completeness but in writing security assumptions into the architecture itself.

Repository address: https://github.com/jondean213-pixel/quietos-sentinel

One-line Summary

The developer uses QuietOS to manage outbound permissions and Sentinel to manage inbound content, building bidirectional gates for personal Agents.

Paragraph Summary

The article introduces a bidirectional security design for personal AI Agents by a developer: QuietOS is responsible for outbound permission control, letting the Agent hold only identity while the gate holds permissions, with approvals that expire and are written as SHA-256 hashes into an append-only ledger; Sentinel is responsible for inbound content review, treating external content such as web pages and emails uniformly as data rather than instructions, intercepting detected external instructions and leaving it to the user to decide whether to allow or terminate, and defaulting to denial when judgment is uncertain. The project has been released on PyPI as 0.1.0 and passes 34/34 benchmark tests, but the developer candidly admits four unfixed vulnerabilities involving synonym substitution, leet spelling, exfiltration in summaries, and non-English override instructions, and it has not yet been deployed on mobile. The overall idea is to place the Agent's security boundary at peripheral gates, with humans always in the loop.