Who can touch your production.

• Your team

  The people at your organisation who already hold a key: push access to your own repository, and whatever DNS or registrar login you choose to keep for yourselves.

  May not: It cannot reach anything on our side directly. There is no console, so a secret's value, a shell, or a live database goes through a request, not a click.

• CustomHosted engineers

  The people who provision, watch, and fix your stack — named accounts, not a shared login.

  May not: It cannot merge or deploy to your repository on its own initiative. Only your own team can, unless you have asked us to hold that step for you.

• The deploy pipeline

  The automated system that builds, checks, and ships every merge — the same one for every change, agent-authored or not.

  May not: It cannot decide to merge or open a pull request. It only ever acts after a person has decided.

• The CodeHerder agent

  Turns a plain-language brief into a pull request, under the Agentic iteration — CodeHerder add-on ($25/mo). It reads your live repository and writes on its own branch.

  May not: It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.

"On request" means it goes through the quote channel, not a console — there isn't one. "On approval" means a principal can start the action but a person has to sign off before it completes.

• A secret lives in one place

  Sent once, at onboarding or whenever it changes, and kept in an encrypted store — never copied into a spreadsheet, a chat message, or a second system to keep in sync.

• It is never in the code

  The running app reads it at startup. It is never written into a file in your repository, so an agent reading the codebase sees the name of the variable your code uses, never the value stored in it.

• You can change it any time

  There is no console to click into — send the new value through the quote channel, and it is stored and rotated in.

• It is redacted from logs

  A build or deploy log shows that a variable was set, never what it was set to — for a person reading the log, or an agent reading the build output.

See Logs for what a log actually holds, and for how long.

• Named accounts, not a shared login

  Every engineer who can reach your stack signs in as themselves — never a shared password the whole team knows.

• A key is scoped to the one job it does

  Deploying your app, reading your backups, running your database — each is its own scoped key, never one master key that opens everything.

• SSH is off by default

  A shell on a dedicated instance is available on request, key-based only, scoped to what is needed — never left open because nobody asked for it.

• Access changes when a job does

  It is not left standing after it stops being needed — see joiners and leavers below for exactly when it is removed.

Read a brief in full on Brief a change, the line-item hand-off on Spec sheet, or what the add-on costs on Billing.

1. 1

   A person joins your team

   Add them to your own repository and DNS panel the same way you would add any other teammate. We are not part of that step, and do not need to be told.

2. 2

   A person leaves your team, or a contractor's engagement ends

   Remove their repo access on your own schedule. If they also held a key to something on our side — a shell login, for instance — tell us through the quote channel and it is revoked the same day.

3. 3

   One of our engineers changes role

   Their access changes with it. A key scoped to your account is removed the day it stops being their job.

4. 4

   One of our engineers leaves

   Every key and account they held is revoked before their last day, not sometime after it.

1. 1

   Elevated access is the exception

   Day-to-day work runs on the named, scoped access described above — not a standing key to everything.

2. 2

   Used only to stop or fix a live incident

   Opened when routine access cannot resolve a real problem fast enough, not as a shortcut around the normal path.

3. 3

   Every use is recorded

   What was opened, by whom, and why, goes in the incident record — not a quiet, unlogged detour.

4. 4

   You are told

   Elevated access used on your stack is named in the incident note you already get — see Monitoring for the shape of that note.

1. 01Do you support single sign-on for my team?

   There's nothing here for it to connect to. Your team has no login console at all — access to your stack runs through your own repository and DNS, so add or remove a person there, not in a dashboard.

2. 02Who can actually deploy to production?

   Your own team, by merging to your repository — the same pipeline that already ships every other change. We can deploy or roll back on your behalf, on request. The CodeHerder agent never can, on its own.

3. 03Can the CodeHerder agent read our secrets or our database?

   No, on both counts. It reads your application code to brief and open a pull request. It never sees a secret's value, and it never opens a connection to your database.

4. 04How do I revoke access when someone leaves?

   For your own team, remove their repository and DNS access yourself, whenever you choose. For anything they held on our side, tell us through the quote channel and it is revoked the same day — see Joiners and leavers above.

5. 05Is this audited or certified by a third party?

   No. This page describes real, current operating practice, in writing — it is not a substitute for a formal audit or certification if your situation specifically requires one.

6. 06What's the difference between an on-request and a break-glass action?

   An on-request action is routine — reading a secret's value, restoring a backup — worked through the quote channel on your schedule. Break-glass is the exception: elevated access opened only to stop a live incident, always recorded, and always told to you afterward.