Platform-attested identity removes a workload's stored secret — what does the platform-signed document still fail to prove?
answer
- the slot, not the code
- who can schedule work there
- everything inside shares one identity
- deploy rights become store rights
- code integrity is a separate control
basics
~20 sIt proves the platform placed work in a slot and will vouch for that slot — not that the code running there is what you reviewed. Anyone who can put code in that slot gets an identical document.
solid answer
~40 sThe signature asserts one thing: *the platform believes this workload identity is running, now*. Three limits follow. It attests the **slot**, not the artifact — swap what is deployed there and the platform signs for the new thing just as readily. Whoever can schedule work into that slot, or change what runs in it, can obtain an identical document, so store access inherits the strength of your deployment controls. And everything inside the workload shares it: a compromised dependency, a debug path that will fetch a URL on request, or anyone with a shell on the running instance can ask for a document and present it. What you bought is real — no long-lived value left to leak, and every restart authenticates as itself. What you did not buy is code identity.
go deeper
Recall the shape of the claim: the platform says which workload it is running, and that is all the signature covers.
Explain why the document describes a slot rather than an artifact, and why anything running inside the workload can obtain and present it.
Show that you have reasoned about the consequence: deploy rights become store rights, a compromise inside the process authenticates successfully every time, and the rule attached to the identity is the real ceiling.
The judgment call is how much of the estate's trust you are willing to move into deployment governance, and what you build alongside attestation — admission-time artifact checks, narrow identities — so that one platform control is not carrying everything.
## What the signature actually asserts When a platform signs a short-lived identity document, it is making a narrow statement: *at this moment, I am running a workload under this identity, and this document describes it*. It is an assertion about the platform's own scheduling records. It is not an assertion about source code, about a build, about who approved the deployment, or about the intentions of whatever is making the request right now. That is worth dwelling on, because the sales pitch for platform attestation — *your workload holds no secret at all* — is true and invites a much larger conclusion than the mechanism supports. ## The three ceilings 1. **It attests the slot, not the code.** The platform vouches for the place it schedules work into. Replace the artifact deployed there and the platform signs for the replacement with the same subject and the same readiness. The document cannot distinguish the version you reviewed from the one somebody pushed forty minutes ago. 2. **Whoever can schedule into the slot gets the identity.** Anyone able to deploy to that slot, change what runs there, restart it with different contents, or attach to the running instance obtains a document that is byte-for-byte as acceptable as the legitimate one. Platform-attested identity therefore converts *deploy rights* into *store rights*, quietly and completely. 3. **Everything inside the workload shares it.** There is no per-component identity inside a process. A compromised library, a debugging path that will make an outbound request on demand, an operator with a shell, a crash handler that dumps memory — any of these can obtain a document and present it, because obtaining one is exactly what the legitimate code does. ## What teams assume against what is true | What teams assume | What is actually true | |---|---| | The store knows the reviewed artifact is calling | The store knows the platform scheduled this workload identity | | There is no credential left to steal | There is a credential; it is minted on demand and expires quickly | | Only the application code can authenticate | Anything running inside the workload can request and present a document | | Deployment access and secret access are separate | Deployment access is now a route to secret access | | A signed document cannot be misused | It can, by anyone holding a copy, until it ages out | ## What you genuinely bought The honest gains are substantial, and a candidate who answers only with the limits has missed half the question: - **No long-lived value to leak.** Nothing is written into an environment, a rendered configuration file, a repository or a ticket. The class of incident where a static credential is found somewhere it should not be simply does not have a value to find. - **Expiry without an operator.** The credential ages out on its own; nobody has to remember to withdraw it. - **Per-restart, per-request identity.** Every restart proves itself, and each call can carry a fresh document, so the store's record of who called is a record of workload identities rather than of one shared value. - **A smaller and more legible exposure.** The question *who could have read this value* becomes *who could run work as this identity*, which is a question your platform can actually answer. ## Where code identity is enforced instead If what you need is confidence that the running artifact is the one you reviewed, the store is structurally the wrong place to look for it. By the time a document exists, the decision to run the workload has already been made. That control belongs where work is admitted to run — the gate that decides whether this artifact may be scheduled at all — and the store's check cannot substitute for it. The two controls compose: admission decides *what may run*, attestation tells the store *what is running*. ## What to do at the store once you accept the ceiling - **Treat deployment governance as part of the store's threat model.** Review who can create, rename and schedule into slots with the same seriousness as who can read the store's values. - **Keep each identity's reach narrow.** Because anything inside the workload can present the document, the rule attached to that identity is the real ceiling on a compromise inside it. - **Keep the window short.** A copied document is usable for as long as the store will accept it, and nothing can be recalled. - **Expect the signal to be a successful read.** An attacker standing where the workload stands authenticates successfully every time, so watching failed authentications tells you nothing here. What is visible instead is a read at an unexpected hour, at an unusual volume, or of values this identity has never needed.
- If the document proves only the slot, what is actually improved over a stored secret?A great deal. There is no long-lived value written into an environment, a configuration file or a repository, so there is nothing to find, copy or forget to rotate. The credential expires without anyone acting. Each restart authenticates as itself. The exposure moves from every place a static value was ever written to the much smaller, more auditable question of who can run work as that identity.
- Someone gets a shell on the running instance. What do they have?Exactly what the workload has: they can ask the platform for a document and present it for as long as they hold the shell. There is no extra secret to steal because there is none — which is precisely why the rule attached to that identity is the whole ceiling on the incident, and why a broad rule undoes the design.
- Where would you enforce that the artifact is the one you reviewed?At admission — the gate that decides whether this artifact may be scheduled at all — not at the store. The store only ever sees a document minted after the decision to run was made, so the only question it can answer is which identity is calling. The two controls compose; neither substitutes for the other.
The building pass proves that the desk in the corner is a real staffed desk the company keeps — not that the person who sat down at it this morning is the one you hired.
saying these in an interview costs you the question
- Says a signed identity document proves the running artifact was reviewed.
- Treats deploy access and secret access as unrelated permissions.
- Assumes a compromised dependency inside the workload cannot obtain the document.
- Claims removing the stored secret removes the impersonation risk.
- Expects failed-authentication alerts to catch misuse of the identity.