Assume something is already inside.

Most security starts with a wall. Keep the attacker out, and everything inside can trust everything else. Our second Flight Rule starts from the opposite end: assume something is already inside. We design every system as if the attacker already has a key. Then we make the key not enough.

Why the wall stopped being the point

The actor that matters most is no longer the stranger at the gate. It is the one with legitimate access: a person with a valid login, or, more and more, an AI agent that was handed credentials so it could do its job. An agent with a payment key can charge a card. An agent with deploy rights can ship code. When it is wrong, confused or hijacked, it is wrong from inside the wall, with a real key in its hand.

So the useful question is not “how do we keep it out?” but “what can it do once it is in, and how do we know?”

What the rule looks like in our instruments

Ratchet holds nothing worth stealing. It gates actions that can’t be taken back, but it never touches the vendor: no credentials, no outbound access, no proxy. Your code does the work and reports what happened. If someone took over Ratchet, they would find a ledger, not a payment key. And a budget the agent can’t raise means a hijacked agent hits a ceiling instead of a bank balance.

Crimp can’t be talked into a verdict. An agent submits a rule and facts, never a conclusion, and there is no field where it could assert one. A compromised agent can propose a bad rule, but a bad rule is visible, reviewable and reproducible in a way a bad conclusion never is. Crimp itself holds no credentials and executes nothing.

Clockford™ keeps its methods to itself. We publish what it does for you, and we withhold how it does it until launch. Assuming something is already inside includes assuming someone is reading our website.

What the rule looks like on this site

The page you are reading follows the same rule. Its Content-Security-Policy lets only our own code run. It sets no cookies and carries no client-side analytics, so there is no third-party script waiting to be the thing that is already inside. Our security page fetches its own response headers and prints them, so you can check this rather than take our word for it.

What you can check today

Ratchet and Crimp each hold the OpenSSF Best Practices Silver badge, projects 14440 and 14613. Both are open source under Apache-2.0, so the code that enforces these rules can be read line by line. Crimp’s v0.1.0 release is signed, and the build of this site fetches its published SHA-256, a76f21d53944…38a6, from the release itself, so the digest in our Record is the one on the release and not one we typed.

None of that proves a system is secure. It proves something narrower and more useful: that the claims are checkable, and that we expect you to check them.

How we work, without the methods

Defence code is reviewed by someone who did not write it before it ships. We run red-team drills against our own systems, and the fixes land before the claims do. Nothing ships on a claim we can’t prove. And we build shields only: no retaliation tools, no reaching into other people’s systems, metadata only where we observe the public web.

Where the rule is going

The old computer-security criteria were written for machines and the people cleared to use them. The Pastel Series is our research revisiting them for a world where the actor inside may be a person or an AI agent. It is unpublished and in progress. The rule it starts from is the one in this note’s title.