Identity, Secrets, and Key Management

Identity, Secrets, and Key Management is 1.6% of the CCDV-F blueprint. It tests keeping three identities apart, why a context window is a publishing channel, how credentials escape an agent, and the order of operations for rotation.

Written by Kiran Manne

1.6% of the CCDV-F blueprint, which is roughly 1 question of 53. It sits inside Security and Safety, worth 8.1% in total.

Identity, Secrets, and Key Management is weighted at 1.6%, which is about one question, and it rewards a specific habit of mind rather than a body of knowledge: keeping straight which identity is doing what.

Three of them are in play whenever an agent acts. There is the human who asked for something. There is the application, holding a credential for the model provider. And there is whatever credential the agent presents to each downstream system it touches. Most failures in this area come from collapsing those into one, because a single powerful service account used for everything produces over-privilege on the way in and an unusable audit trail on the way out: every action is attributed to the application rather than to the person who caused it.

The secrets half is conventional practice with one twist particular to model-backed applications. A context window is a place secrets go to be persisted. Anything in a prompt, a message, a tool description or a memory file is written into conversation history, may be captured in a cached prefix, and will likely appear in logs and traces. A credential that reaches the context has effectively been published, which is why the storage rule is not a matter of taste.

One question, small surface, easy to secure.

What the exam tests here

Separating end-user identity, application identity and the credential presented downstream
Why anything placed in a prompt or a message should be considered persisted and disclosed
The routes by which a key escapes an agent, including error text and environment dumps
Rotating a credential without an outage, and what to do first when one is exposed
Delegated, per-user authorization instead of a single shared account for a multi-user agent

Three identities, kept apart

Answer three questions for every privileged operation an agent performs. Who asked for it, what is executing it, and whose authority is being spent on the target system. Keeping them distinct is what makes least privilege expressible at all: the application's own credential can stay narrow because it only needs to reach the model provider, while access to a customer's records is granted per request against that requester's entitlements.

Collapsing them is the common design and it fails in two directions simultaneously. A shared account able to reach everything means any successful manipulation of the agent reaches everything too, and the log afterwards records only that the service did it. Attributability is the part people skip, and it is precisely what an incident review needs.

The context window is not a vault

Anything placed into a prompt, a user message, a tool description or a persisted memory file has been written down. It joins the history resent on every subsequent turn, it may become part of a cached prefix outliving the request, and it will be present in whatever logging, tracing and debugging output the application produces. None of that is reversible afterwards.

So credentials are read by the harness from the environment or a secret manager and used in code, never handed to the model at all. The practical test is to ask what you would have to do if a value leaked. If the answer is to rotate it, it does not belong anywhere you cannot fully enumerate, and conversation history is exactly such a place.

Know how keys actually escape

The leaks worth guarding against in an agent are mundane. An exception message containing a request with its authorization header, returned into the conversation as a tool result. A diagnostic that prints the environment. A shell command the agent runs that displays a configuration file. A server configuration committed alongside the code referencing it. A transcript pasted into an issue tracker.

Two habits cover most of it. Redact before anything leaves your process, stripping credential-shaped values out of error text and tool output rather than trusting they will not appear. And restrict what the agent can reach: if a shell tool exists, its environment should not contain the keys the surrounding application uses, because the agent is one instruction away from printing them.

Rotation, revocation and the order of operations

Rotation is only painless when the system can hold two valid credentials at once. Issue the new one, deploy it, confirm traffic has moved, then revoke the old. Doing it the other way round produces the outage that teaches a team never to rotate again, and unrotated keys are how an exposure from two years ago remains exploitable today.

A suspected compromise inverts the priority: revoke first and investigate afterwards, because the window matters more than the diagnosis. Prepare by keeping credentials narrowly scoped and separated per environment and per service, so revoking one does not halt everything, and by knowing in advance where each lives and what depends on it. The recovery plan only exists if it was written before it was needed.

Where candidates go wrong

Trap 1: one service account because it is simpler

It is simpler, and it converts every access-control question in the system into a single point of total failure. The agent inherits the union of everything that account can do, so a manipulation which would have retrieved one person's record retrieves anybody's, and the trail afterwards cannot distinguish the two cases.

Answers justifying a broad shared credential on grounds of operational convenience are the ones to set aside. The design being tested issues authority per request, scoped to the person or the task.

Trap 2: forwarding the token you were handed

Receiving a valid token and passing it along to the next service is an appealing shortcut, because it appears to preserve the caller's identity. It breaks the assumption every recipient makes about who a token was issued for, defeats any ability to reason about scope, and turns each component in the chain into a potential credential harvester.

The pattern to reach for instead is an exchange: present your own identity and obtain a credential intended for the specific service you are about to call.

Trap 3: a configuration file the agent can read

Moving a key out of the prompt and into a file in the working directory feels like remediation and frequently is not, because a coding agent with filesystem access can open that file and quote its contents into a response the moment something prompts it to.

Storage location matters less than reachability. Keep secrets outside the paths the agent operates on, inject them into the process rather than the workspace, and deny the tools capable of reading them.

Common questions

How much of the CCDV-F exam is Identity, Secrets, and Key Management?

1.6%, so roughly one question of 53. It is the second-smallest sub-skill in its domain, ahead only of Claude Hooks, and the material is small enough that a single careful read should be sufficient.

Why is a key in a prompt worse than a key in a configuration file?

Because a prompt is copied forward. It joins the conversation history resent on every turn, can be captured in a cached prefix, and lands in traces and logs, so the exposure is distributed across systems you cannot fully list. A file has one location, which is at least enumerable, though it is still reachable by any agent with filesystem access.

How should a multi-user agent authenticate to a third-party service?

Per user, through a delegated authorization flow, so that each person's own consent and scopes govern what the agent can reach on their behalf. A single shared account means the agent can always touch everybody's data, and the resulting log cannot say which request belonged to whom.

What is the first thing to do when a key is exposed?

Revoke it. Investigation, root cause and process improvement all matter and all come second, because every minute the credential stays valid is a minute somebody can use it. Being able to do that quickly depends on having scoped and separated credentials beforehand, so revoking one does not take the whole system down.

The rest of Security and Safety

Practise this

The CCDV-F bank covers every sub-skill in the blueprint, weighted the way the real paper is. Free sample questions need no account.

Free CCDV-F questions