Security

That is the whole posture, and we are going to defend it rather than dress it up. Plenty of products in this space advertise a confirmation prompt in front of every command and let the buyer infer that the prompt is the security. It is not. It is a user interface element that converts a security decision into a reflex.

Think about what a per-command tap actually asks of a person. It arrives dozens of times an hour, in the middle of other work, attached to a command they did not write, describing an effect they would have to reason about carefully to evaluate — and the correct answer is "approve" almost every single time. Human beings are extremely good at learning that pattern. Within a week the tap is muscle memory, and the one command in three thousand that deserved a hard look gets the same half-second of attention as the two thousand nine hundred and ninety-nine that did not. The prompt did not add a control. It added latency, and it moved the blame from the system to the person who clicked.

So v10.0 spends its security budget somewhere the machine can be relied on. Every privileged job is bound to a cryptographic signature over its own identity and its own contents, executed by a component that can verify that signature and cannot forge it, in an environment stripped of everything it does not need, with an immutable record of what happened. That is a control. It works at three in the morning, it works on the ten thousandth command, and it does not get tired.

What the journal holds

The journal is the accountability mechanism here, and it is worth being precise about the trade it represents. A prompt is a control that happens before and depends on a human being alert. A journal is a control that happens always and depends on nobody. Given one budget and a choice between them, the second is the one that survives contact with a Tuesday afternoon.

On a default install, install.sh sets PC_AUTO_APPROVE=1: a staged job is signed and run in the same call. Set it to 0 and a staged job goes to pending and does not run. Not on a timer. Not on a retry. Not when the queue drains, not when someone reconnects, not ever. There is no background worker that comes along later and picks pending jobs up, because building one would recreate exactly the risk the setting exists to remove.

# shipped defaults, written by install.sh
PC_AUTO_APPROVE=1      # stage + KMS-sign + execute in one call, journalled
PC_GUARDRAILS=0        # set 1 to restore two runtime refusals
PC_REQUIRE_PASSKEY=0   # set 1 to re-arm the whole WebAuthn layer

# PC_AUTO_APPROVE=0  ->  staged job becomes `pending` and is never executed.
#                        Not on a timer. Not on a retry. There is no queue
#                        to approve it from, and no per-job tap anywhere.

So PC_AUTO_APPROVE=0 is a fail-stopped mode, not a fail-slow one. It is the right setting for a substrate you have deliberately frozen, for a demonstration environment, or for the interval between noticing something wrong and understanding it. It is the wrong setting for a working install, because it does not make the work safer — it makes the work stop.

The two other switches

Why the third control is a different kind of thing

Dwell on this one, because it is the difference between a policy and a control, and most security programmes never notice they only bought the first.

A policy is a sentence in a document: "do not grant console access to personal accounts". It is true, it is sensible, everyone agrees with it, and somebody does it anyway. Not out of malice — out of Friday. A contractor needs access for two hours, their corporate account is not provisioned yet, the deadline is real, and the grant takes eleven seconds. The policy was never violated by a person who disagreed with it. It was violated by a person who agreed with it and had a problem.

allowedPolicyMemberDomains is a control because it refuses the write. The eleven-second workaround returns an error. The person with the deadline has to do something else — provision the corporate account, use a different mechanism, or escalate — and any of those outcomes is better than the one where an identity outside your domain quietly holds a binding on the project that stages privileged jobs.

Approvals are Cloud KMS asymmetric signatures. The control plane holds the private half; the executor holds only the public half. The consequence is the sentence in the heading, and it is the design's whole point: the executor can verify that an approval is authentic, and it has no ability whatsoever to manufacture one. Compromising the executor gets an attacker the power to refuse valid jobs. It does not get them the power to authorise anything.

The signature covers the job ID and the command digest, together. Privilege elevation is therefore bound to one specific job running one specific command. Edit the command by a byte after signing and the digest no longer matches: the job is refused. Replay a valid signature against a different job ID and the binding fails: refused. There is no approval in this system that means "this strain may run things"; every approval means "this job may run this command", and nothing else.

Why zero datastore access is the strongest line in the table

An executor that could consult a database would have a second input, and every second input is a second thing to compromise. It would mean an attacker who could write to the right document could change what the executor decides — without touching the key, without forging a signature, without going anywhere near KMS. Denying the executor any datastore at all collapses its decision surface down to the signed material in front of it. There is nothing to poison because there is nothing to read.

It also makes the component genuinely auditable. You do not need to reason about the state of your database to know what the executor will do. Its inputs are the job, the command, the signature and the clock. That is a small enough set to hold in your head, which is a property worth more than most features.

stage -> sign(job_id + sha256(command))          [control plane, KMS private half]
      -> verify(signature)                       [executor, public half only]
      -> compare sha256(command) == approved_sha256
      -> check staleness window
      -> atomic single-use claim  (exactly one winner)
      -> exec in PATH jail, hard timeout
      -> write result object (create-only)
      -> journal: who staged it, the command, what it returned

Session cookies are HMAC-SHA256. The layer fails closed on a weak secret: a secret that does not meet the requirement is not accepted with a warning in a log nobody reads — it refuses to serve. The failure mode of a session layer configured badly should be "nothing works", loudly, on the first request, rather than "everything works" and a forgeable cookie.

401 in place

An unauthenticated request gets a 401 where it stands. No redirect to a login page. No ?next= parameter carrying the URL you were trying to reach. No WWW-Authenticate prompt from the browser.

The ?next= detail is small and it matters. A login redirect that preserves the destination is an enumeration oracle: an unauthenticated attacker can walk a list of candidate paths and read the difference between "this route exists and wants auth" and "this route does not exist" straight out of the redirect behaviour, and they can do it without any credential at all. It is also a stock open-redirect surface, since something eventually has to decide whether the next value is safe to bounce to, and that decision is a validator that people get wrong. Returning 401 in place answers with the minimum: not authenticated. It does not confirm what is behind the door, and it does not hand an attacker a bounce.

Suppressing the WWW-Authenticate prompt is the same instinct applied to the browser: a native credential dialog on an API surface trains people to type passwords into a dialog that any origin can raise.

IAP consumes the Authorization header. That is not a quirk to work around; it is how the edge does its job. It also means an MCP client — which authenticates with OAuth 2.1 by putting a bearer token in exactly that header — can never live behind IAP. The token would be eaten by the proxy before your service saw it. So there are two services: one behind IAP for humans with hardware keys, one in front of OAuth 2.1 for machines with tokens. Trying to collapse them means giving up either the hardware-key requirement on the console or the standards-compliant auth on the API.

The split is enforced by a 90-entry route table checked at build time. Every route is assigned to exactly one surface, and a route that lands on neither service throws at boot — the same deliberate failure discipline used for the MCP SDK assertion. A new handler cannot be added and quietly served from both places, and the mistake where an administrative route accidentally appears on the machine-facing surface is not a code review's responsibility. It is a build failure.

Nine lockout classes are codified in the source. They block the changes that destroy your own route back to the console — the class of mistake where everything succeeds, the change applies cleanly, and the door is now locked from the inside with the key on the wrong side of it. Among what they refuse:

These are described here by what they protect rather than reproduced as a literal enumeration; the codified list is in the tree and is the authority. The design rule behind all nine is the same: a system that can be bricked by one plausible action will eventually be bricked by one plausible action, and the recovery cost is always paid at the worst possible moment.

The reporting process, the contact route and the expectations for both sides are in SECURITY.md in the repository. That file is the authority; it travels with the code and it is updated with the code, which is more than can be said for a paragraph on a marketing site.

One last framing, because it is the thesis of this entire page. A security control should be judged the way you would judge sterilisation, not the way you would judge a signature on a form. It does not ask permission for each item on the tray. It applies the same uncompromising process to everything that goes in, every time, and it writes down what it did. That is the standard a security control should be held to — not whether it made a person feel consulted, but whether it is still working correctly on the ten-thousandth run at three in the morning when nobody is watching.