๐Ÿ” Security model

Give AI your cloud โ€” keep the keys.

Paracoding is built on one non-negotiable rule: there is no unattended path to root. Your agents can think, plan, and stage any action they like โ€” but the only thing that turns a proposal into a real change on your infrastructure is a human, holding a passkey, in the moment. Here is every layer, honestly.

See the layers โ†“
The one path to a privileged action

Every change takes the same five steps

There is no side door. Not for an agent, not for a stolen token, not for the platform itself.

Step 1
Agent proposes
An agent stages a job โ€” the exact command, nothing hidden.
Step 2
Queued, not run
It lands in a pending-confirm queue and simply waits.
Step 3
You review
You see the literal command before anything happens.
Step 4
Passkey commit
Face ID / hardware key. Destructive jobs ask twice.
Step 5
Runs as you
Short-lived identity executes it, then the result is logged.
Defense in depth on Google Cloud

The layers

Each one is a real GCP control โ€” and each one is here for a reason we can name.

The human gate โ€” AI proposes, a human commits

Agents never execute privileged work directly. They write a staged job to a confirm queue; a job only runs after a human approves it. When we built this, the infrastructure agent itself refused to approve its own deploy โ€” "I stage; the human commits." That property is proven live, not aspirational.

Why it matters for your fleet: the scary failure mode of agentic AI is unattended action. Remove the unattended path and the whole class of "the bot did something at 3am" disappears.
pending-confirm queueone job, one intentfull audit trail

Passkeys are the commit key โ€” Face ID for your infrastructure

Approvals are authorized with WebAuthn / passkeys, bound to your device's biometrics. The first device is enrolled with a one-time setup password that is then permanently disabled; every additional device must be added from an already-trusted one. Destructive commands trigger a second, explicit Face-ID confirmation.

Why it matters: a leaked password or an over-eager agent can't approve anything. The commit key is a physical thing in your hand.
WebAuthndevice enrollment chainstep-up on destructive jobs

"Runs as you" โ€” short-lived identity, not a standing super-key

When you approve a job, it executes under your Google identity via a short-lived OAuth token, valid only inside a 12-hour "ops window" you open with a click and end on logout. There is no always-on service account with god powers sitting in the project waiting to be stolen.

Why it matters: privilege exists only while you're present and intending it. Close the window and the power evaporates.
Google OAuth12h ops windowrevoke on logout

Least-privilege service accounts

The runners and executors that do the day-to-day work are scoped to exactly what they need โ€” typically datastore.user plus read access to a single secret โ€” and nothing more. The scheduler that wakes them can only invoke one service. No component is a project owner; none can redeploy the platform.

Why it matters: if any single piece is compromised, its blast radius is a rounding error, not your whole cloud.
scoped IAM rolesno owner / no deployrun.invoker-only scheduler

Secrets live in Secret Manager โ€” never in an image

Container images ship code and tools only, zero secrets. Credentials are pulled from Google Secret Manager at runtime and injected as needed. The open-source release provisions an empty secret slot; you drop in your own credential. Nothing sensitive is ever baked into a layer that could be pulled and cracked.

Why it matters: a published image can't leak a key it never contained โ€” and you rotate a secret without rebuilding anything.
Secret Managerbring-your-own-credentialruntime injection

Server-verified identity โ€” OAuth 2.1, no tokens in URLs

The control plane is a proper OAuth 2.1 resource server: authorization-code + PKCE, dynamic client registration, discovery documents, Google-delegated login. Each role's identity is derived from a validated token, server-side โ€” so an agent can't simply claim to be another role. An early version once carried a token in a URL where it could leak; fixing that reframed the entire model.

Why it matters: identity is enforced by the server, not honored on the honor system. Impersonation is blocked at the door.
OAuth 2.1 + PKCEDCR + discoveryper-role identity

Deploy hygiene โ€” SHA-pinned, additive, restore-on-fail

Every deploy verifies the source against a known SHA before it builds, passes a type-check gate, and is additive โ€” new capability is layered in without rewriting what already works. If a build fails, the previous revision keeps serving. No outages, no "how did prod change?" mysteries.

Why it matters: the process that changes your infrastructure is itself controlled, reviewable, and reversible.
SHA verificationtsc-gated buildszero-downtime rollback
The honest part

What's earned, and what's disclosed

Security theater is telling you everything is green. We publish a real posture โ€” including the edges we're still hardening โ€” because a threat model you can trust is worth more than one that flatters us.

PropertyStatusWhat that means
No unattended path to rootEnforcedPrivileged actions require a human passkey commit. Proven live.
Server-verified role identityEnforcedIdentity derived from a validated token; roles can't be spoofed.
Least-privilege componentsEnforcedRunners/schedulers scoped to the job; no owner-level access.
Secrets never in imagesEnforcedRuntime injection from Secret Manager; bring-your-own-credential.
The gate is the whole boundaryBy designOnce you approve, the executor can run what you approved as you. That power is why the passkey commit is non-negotiable โ€” review the command before you tap.
Rate limiting on the control planeOperator-setBring your own quotas and budget alerts; we ship the guidance, you own the ceilings.
Credential leak resilienceMitigatedShort-lived, revocable identity limits exposure โ€” but rotate promptly if a device is lost.

Written to survive a real security review โ€” the same threat model ships in the repository so you can audit it yourself.

Why this matters for you

Your fleet should work while you sleep โ€” without acting behind your back.

That's the whole point of Paracoding. Real autonomy for the drafting, planning, and staging. A human on the commit key for anything that touches your cloud. Read the code when it ships, or start with the model.

โ† Back to the overview โ˜… Get it on GitHub soon
This page describes the security architecture of the Paracoding OSS platform. It is engineered so that a human holding a hardware passkey is the sole authorizer of privileged actions, with least-privilege identities and runtime secret injection to limit blast radius. No system that connects automation to cloud infrastructure is risk-free: run it in a project you control, review staged commands before approving them, keep budget alerts and quotas enabled, and rotate credentials if a device is lost. Status labels reflect the platform's posture at time of writing and may change as the release is hardened.