The mandated broker path has no agent-reachable identity — every credential task dead-ends at the human

[chitcommit]

Filing this because it is the structural blocker behind three separate tasks today, and it is not a task anyone can close by trying harder.

What happened

chittyconnect-concierge was dispatched with a concrete, in-scope ask: grant API Tokens Write on the account so the provisioner can mint scoped Cloudflare tokens. It could not execute, and its failure code was not POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE — both broker legs are live:

• connect.chitty.cc/health → 200, v2.2.0
• connect.chitty.cc/api/credentials/{health,types,provision} → 401 Missing API key — mounted and correctly enforcing auth
• secrets.chitty.cc → Cloudflare Access interstitial on every path, gate working as designed

The code was MISSING_CREDENTIAL_MATERIAL. The agent holds no ChittyConnect API key and no ChittySecrets service-principal JWT, so it cannot invoke ch1tty.cast_execute_to_chittyconnect at all.

Why this is the finding and not a footnote

~/.ch1tty/canon/system-wide-sensitive-intent-contract-v1.md makes ChittyConnect the mandatory control path for credentials, deploys, registry mutation, and infrastructure change, and forbids falling back to chat. That contract is sound. But an agent that cannot authenticate to the mandatory path has exactly two moves: fail closed, or route the work to the human.

Failing closed is correct and is what happened. The problem is what happens next — the work still needs doing, so it lands on the one human, which is the precise outcome the contract exists to prevent. The policy is enforced; the capability behind it is not reachable. That gap is why "use the broker instead of the Global API Key" has been advice nobody could follow, and why 34 files still use the account Global API Key.

What would close this

An agent-reachable service principal for the broker: a ChittyConnect API key or ChittySecrets service-principal JWT, scoped to credential provisioning, that a dispatched agent can obtain without a human in the loop and without any secret value transiting a chat surface. Whatever the shape, the acceptance test is one sentence — a dispatched agent completes a credential-provisioning request end-to-end with no human step.

Until then, MISSING_CREDENTIAL_MATERIAL is the honest terminal state for every credential task, and it should be reported as a capability gap rather than as "requires operator action" — the noun does not change what is missing.

Immediate downstream blockers

• The API Tokens Write grant on account-owned token bb924f… (needed by fix(credentials): address Cloudflare account-owned tokens, not the /user token family #281). Whoever holds the account-owner credential must provision it into ChittySecrets; no agent path reaches it today.
• Whether /accounts/{id}/tokens/permission_groups returns the same permission-group IDs as /user/tokens/permission_groups. Unanswerable while 403'd. fix(credentials): address Cloudflare account-owned tokens, not the /user token family #281 now fails closed rather than guessing, so this is safe to leave open — it just means minting stays blocked.
• EnhancedCredentialProvisioner has no path to edit an existing token's permissions (no PUT /accounts/{id}/tokens/{id}), and its static permission catalog has no Account API Tokens group at all. If "extend the existing token" is the intended operation rather than "mint a sibling," that needs new code and is a maintainer design call.

Related: #279 (end-to-end retrieval acceptance test), #280 (broker adapter), #281 (account token API family).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nz8PYvgzrfpm9hM86vSWBc

[chitcommit]

Probe matrix: three distinct identities, none with API Tokens scope

This issue was filed on inference from a single dead-end. It is now evidenced by
measurement. Every probe below is read-only; no credential value was retrieved,
displayed, or handled.

1. The provisioner's bearer (bb924f…, account-owned)

Call	Result
GET /accounts/{acct}/tokens/verify	success:true, status:active
GET /accounts/{acct}/workers/scripts	200
GET /accounts/{acct}/tokens/permission_groups	9109 "Unauthorized to access requested resource"
GET /user/tokens/permission_groups	9109 "Valid user-level authentication not found" (wrong family — fixed by #281)

Valid token, missing the API Tokens Write grant.

2. This session's user-authorized Cloudflare identity (the CF MCP)

The path named as the answer — "chittyconnect/chittysecrets has cf mcp access
scoped for api token minting". Measured, it is not scoped for that:

Call	Result
GET /accounts	200 (4 accounts)
GET /accounts/{acct}/workers/scripts	200 (120 scripts)
GET /accounts/{acct}/secrets_store/stores	200 (1 store, 60 secrets)
GET /accounts/{acct}/tokens	9109
GET /accounts/{acct}/tokens/permission_groups	9109
GET /user/tokens/permission_groups	9109

Reads Workers and Secrets Store fine; 9109s on every API-token endpoint.
(/tokens/verify returns 1000 Invalid API Token here — that rejects the
credential type, an OAuth bearer rather than an API token. It is not evidence
the credential is broken.)

3. chittyagent-cloudflare — the deployed agent that holds a CF API token

Binds CF_API_TOKEN_CHITTYCORP (secret_text). Live at cf.ai.chitty.cc,
chittycorp account reachable: true. This is the closest thing to a sanctioned
minting path that exists. It does not mint:

• GET /health → capabilities: ["workers","kv","r2","dns","domains"] — no tokens capability
• GET / and /openapi.json → 403 Missing CHITTY_AUTH_SERVICE_TOKEN in env

So it neither exposes token operations nor admits a dispatched agent: its whole
API surface is gated behind an inbound service token that no dispatched agent
holds. That 403 is a second, independent instance of this issue's core claim —
the same shape as chico's 401 Missing API key from ChittyConnect.

One correction, so it does not get re-derived

CF_ACCESS_CLIENT_ID/SECRET_CHITTYAGENT is provisioned and bound into both
chittyconnect and chittysecrets. That looks like a refutation of this issue
and is not one: it is an egress credential those workers present to get
through an Access-protected origin. This issue is about an ingress
credential — something a dispatched agent presents to call in. The two are
orthogonal, and the Access material does not close this gap.

What this changes

Nothing about the acceptance test, which still reads: a dispatched agent
completes a credential-provisioning request end-to-end with no human step.

What changes is confidence. Three separate identities were tested; none can read
the account permission-groups catalog, so none can mint. #281 makes the
provisioner fail closed on exactly this (POLICY_BLOCKED_PERMISSION_CATALOG_UNAVAILABLE)
rather than minting from unread fallback IDs — a correct failure, still not a
success. The permission-group ID equivalence question between the /user and
/accounts catalogs stays unanswerable until one identity can read one catalog.

The narrowest fix that would close this: give chittyagent-cloudflare a tokens
capability and an inbound identity a dispatched agent can present. That is one
service gaining one scope — not a new subsystem.