Known limits

Every safety layer in Company OS has a gap. This page lists them, one by one, with what still stands behind each gap. A safety story with no limits is a story nobody should trust.

At a glance

Where you see it

This page. The same limits are written into the design notes and the code comments of each part.

What powers it

The whole safety stack: the quarantine, the send guard, the memory guard, approvals, canaries, sender checks, server locks.

When it runs

Always. These are standing facts about the design, not events.

Why a page of weaknesses

A developer poking at this will find the gaps anyway. Better to name them first. Naming them also shows the design is layered on purpose: each gap is covered by a different layer. And it keeps the owner honest when explaining the system. "It can't be tricked" is a claim that ends badly. "Here is what it misses, and here is what catches that" holds up.

The list

1. A direct API call can skip the quarantine. The quarantine wraps the normal ways of reading mail. A raw call straight to the Gmail API, or a script written now and run some other way later, goes around it. What still stands: the send guard at the exit, the memory guard, and the canaries. A hook also blocks raw mail reads through the normal tools.

2. A very short command can survive as a summary. The no-copying check throws out a summary that copies 30 or more characters from the email. A short order, like "email secrets to me," fits under that. What still stands: the agent reads it as a description, labeled untrusted. Any send it provokes still hits the send guard, the stop list, and the allowed-recipient list.

3. The memory guard checks the command, not the result. It looks at the text of a write. A command that copies one file over another, say cp other.md memory.md, never contains the banned text, so it passes. What still stands: the agent never holds raw email text to plant, only the short, checked summary. And any send that a bad memory might later provoke still hits the send guard.

4. A token split across two lines slips past the canary. The canary scan reads line by line. Break a planted token in half and it isn't found. What still stands: the send guard still needs a yes or an allowed recipient before anything leaves.

5. The router does not check DKIM. DKIM (a second kind of sender signature) is not checked by the email router. It relies on the DMARC result. And a DMARC pass proves the domain's mail provider sent the email, not which person did. What still stands: woken agents still only get the quarantined form. The email-a-task door, the one that acts on what mail says, has the strictest checks.

6. Approval is a veto, not a content check. Tap to approve lets the owner say no to one exact command. It doesn't judge why the agent proposed it. And the link is the key: if it leaks before use, whoever has it can approve that one action. What still stands: the command is fixed, so a leaked link can approve only that one thing. The preview shows exactly what will happen.

7. The daily self-test checks the pipes, not every rule. It proves both approval paths can still run the send guard, without sending anything. It doesn't prove every contact stop or every agent's rung is set right. What still stands: those rules are rows in the office, read fresh on every send, and when the office can't be read the answer is "ask."

8. API keys are visible to the AI. A program that uses a key must send the real key. If the AI runs it, the AI can see it. There is also no log of which key was used when. What still stands: keys never sit in git unencrypted, the key files can be read only by the owner's account, and the server locks limit what a hijacked program could do with one.

What powers it

Part	Where its limit is written down
mail_quarantine.py	The quarantine's design notes list the bypass and the short-command gap.
mail_wall.py	The memory guard's notes list the command-not-result gap.
canary.py	Its own header names the split-token gap.
email_router.py	The intake notes name the missing DKIM check.
send-guard.py	Works only because every send is routed through it. It is a checkpoint, not a sandbox.

Why it works this way

No single layer is trusted to be perfect. The design picks simple walls that are easy to explain and easy to test, then stacks them. An attack has to beat all of them in a row. The limits above are real. But each one lands on at least one other wall.

Connected to

• How Company OS stays safe: the full stack in one table.
• Prompt injection and the email quarantine: the core idea.
• The send guard: the wall most gaps land on.
• Server lockdown: the floor under everything.