Ship auth,
not infrastructure

Before you switch it on

What leaves

The snapshot is assembled one field at a time, so a setting reaches the advisor only because somebody added it there by name. Where a value cannot be shown, what is shown is what can be concluded about it: a signing key contributes its age and whether it is overdue for rotation, never its material.

Leaves for analysis

• This client’s protocol, token and password settings
• How old its keys and secrets are
• Its sign-in successes and failures, added up

Never leaves

• Client secrets
• Passwords and password hashes
• Private key material
• Machine credentials and API keys
• Anything that identifies one of your users

None of that is stripped out of what is sent. None of it is ever put in. The sign-in figures are counts the database computed, and no individual row of the access log is read at any point, so an address, a username or a failure message has nothing to be removed from.

Where it goesclaude-haiku-4-5

One provider, Anthropic’s Claude, reached from one file. Every capability runs on the model below unless a deployment names another one. The standing instruction is byte-identical for every account, because what belongs to your tenant travels in the request and never in the part that is cached.

What it can change

One capability out of the thirteen that call a model can write to a client, and only when you press Apply on a proposal you have read — there is no path in the product that applies one on its own. It writes through the same validated, audited route your own edit takes, over a fixed list of sixteen settings that does not include client secrets or redirect URIs, and it records what each setting held so it can be put back. If the client changed while the proposal was sitting there, Apply is refused rather than resolved for you.

Three of the sixteen

• Protocol.PkceRequired
• TokenPolicy.AccessTokenLifetimeMinutes
• Lockout.MaxFailedAccessAttempts

Who turns it on

Reading a client’s configuration is off until somebody in your account switches it on, per realm or per client. A client’s own decision wins in either direction: it can be read inside a realm that opted out, and left out of one that opted in. Four things sit outside that switch, and they are named here because you would find them anyway. Turning a typed sentence into an audit filter sends your realm and client names, so the sentence has something to be matched against. A documentation answer sends only the passages the console already had. A token reading sends the shape your browser reduced a token to, and the server rejects the request outright if anything in it still looks like a token. An import pre-flight sends counts. None of the four sends a configuration.

What a run costs you

This is bounded twice: a run allowance on your plan, counted per calendar month in UTC rather than per billing cycle, and a per-minute request limit under it. A client review, a configuration proposal and a dashboard reading each spend one run of that allowance. The console reads the figure it shows you from the same place the platform reads it when it refuses a run, so the number you are shown and the number you are held to cannot disagree. A plan that names no ceiling is not capped.

Switching it off

Withdrawing consent is recorded rather than deleted, so “never asked” and “asked and declined” stay different answers. Undoing a proposal that was applied is deliberately not gated on consent still being on, so switching the advisor off does not strand a change it made. And where a deployment has configured no provider credential at all, every one of these endpoints refuses at the moment of asking rather than accepting work it will never do.

None of this is in the sign-in path. Every one of these endpoints lives under the admin API: not in the token endpoint, not on the login page, and not in anything your users ever touch.