Secrets, Tokens, and Blast Radius

By the end of this lesson, you will be able to...

• Trace how a credential's scope, lifetime, delegation, and revocation properties change the reachable part of an attack path.

• Compare two credentials by the damage they could enable from the same starting position.

• Identify the boundary that reduces blast radius without assuming that a secret manager or MFA alone solves authorization.

Idea in one sentence: A credential is a capability, so its scope and lifetime determine how much of the system moves with it when it is misused.

Core Insight

Northstar has corrected its shared-link rule: confidential documents now require an explicit recipient. The direct path from a support ticket to Ari viewing a roadmap is blocked at authorization.

But support still needs a way to investigate document-display problems. It can use a support-access token that lets the support service read a document’s rendering metadata for a short time. One proposed version of that token can read metadata for any company document for thirty days. A second version is limited to one document, one support case, and fifteen minutes.

Both are “tokens.” That label hides the important difference. If either token is used outside its intended workflow, the first one reaches far more documents for far longer. The token has changed the next available gates in the path.

The tempting model is, “A secret is safe if it lives in a vault.” Storage matters, but it answers only one question: where is the capability kept before use? It does not answer what the capability permits, how long it remains useful, whether it can be passed on, or how quickly a team can make it stop working.

The stronger model is to treat every secret or token as a capability with a blast radius. Blast radius is the set of assets, actions, identities, and time windows that become reachable if that capability is used wrongly. The goal is not to eliminate every credential. It is to ensure that one capability cannot silently become a larger authority than the workflow needs.

The Small Situation: Two Support Tokens

For this fictional system, hold these facts fixed:

These are teaching facts, not claims about a particular token format. The lesson does not explain token construction, cryptographic signing, key rotation, or vault configuration. Those belong to the cryptography and identity tracks.

The product promise is: support can diagnose a display problem without gaining a standing ability to inspect unrelated confidential documents.

The broad token looks convenient because it avoids issuing a new credential for every case. That convenience works while every use remains correct and the support service is the only place the token can act.

It breaks when a workflow, account, or service state uses the token outside that narrow intent. The relevant question becomes not “is the token secret?” but “what can this capability reach before its next boundary stops it?”

The Moving Parts: Authority Is More Than Possession

Separate four properties:

Possession is only the starting state. A token becomes consequential when a system accepts it for a particular action on a particular resource. MFA can help establish who signs in; it does not automatically constrain what a valid support service can do after it has a broad token. A vault can reduce accidental exposure; it does not automatically shorten a token’s lifetime or narrow its audience.

Plain meaning: ask what the credential can unlock, for whom, for how long, and how it can be taken back.

Technical name: this is capability and blast-radius analysis. It applies to API keys, service credentials, browser sessions, recovery codes, signed links, and delegated access—not only things literally called tokens.

The Mechanism Step by Step

Trace the same support request under the broad token. This is a fictional reasoning trace, not an access procedure.

Starting state
  Support opens case C-17 for rendering metadata on roadmap R-42.

Authority issued
  The service can use a token with metadata-read permission for any company document.

Normal use
  The service reads metadata for R-42 and resolves the display problem.

Boundary question
  Nothing in the token itself limits the next metadata request to C-17 or R-42.

Consequence
  The same capability could reach metadata for other documents until it expires or is revoked.

Signal and stop
  A policy-relevant use could be recorded, but the system relies on later review or manual revocation to contain it.

The token did not need to be copied or technically broken for the blast radius to be large. Its normal authority was already substantially broader than the case explicitly required and justified.

Now trace the case-bound version:

Starting state
  Support opens case C-17 for rendering metadata on roadmap R-42.

Authority issued
  The service receives read-metadata authority bound to C-17, R-42, and fifteen minutes.

Normal use
  The service reads metadata for R-42.

Next request
  A request for another document, a different action, or a use after expiry is rejected by the stated bounds.

Consequence
  A wrong use can still affect R-42 during the short window, but it does not automatically reach the rest of the document set.

The stronger model does not claim that the second token is harmless. It narrows the reachable state. It also makes the support case and document boundary visible to a reviewer.

A Capability Map Makes the Difference Visible

This table is a teaching model, not a score. Do not multiply numbers and call the result risk. The right comparison depends on asset sensitivity, the evidence available, the cost of issuing scoped authority, and whether the boundary is actually enforced.

So far, we have seen that blast radius is not the same as likelihood. A broad token may be well protected and rarely misused; it still creates a larger possible consequence if a relevant boundary fails. A narrow token may be used often; it still limits how far one use can reach.

Where the Model Breaks

Two mistakes are common.

First, “short-lived means safe.” A short token can still permit a high-impact action during its short lifetime. Lifetime reduces the window; it does not replace scope limits or monitoring.

Second, “read-only means harmless.” Reading metadata or content may still disclose sensitive information. The action scope must be compared with the asset and product promise.

There is also a boundary beyond credential properties. If the support service can ask another highly privileged service to perform arbitrary work, narrowing its own token may not contain the real path. Delegation and downstream authority must be included in the map. The next question is always: after this capability is accepted, which identity or service can act next?

Cost, Limits, and Signals

Scoped, short-lived authority improves containment. It costs issuing logic, support workflow changes, and recovery paths when a legitimate case lasts longer than expected. Strict binding can also make debugging slower. A team may choose a broader temporary scope when its operational constraints justify it, but should name the owner, expiry, audit evidence, and residual risk.

The trade-off is not “strong security versus usable support.” It is choosing the smallest authority that lets the workflow finish reliably, then designing an accountable exception when that authority is insufficient.

Signals reveal the boundary: a capability used outside its case, after its expected window, or against an unexpected resource suggests that either the token bounds or the workflow assumptions deserve review. Those signals are prompts for the owners from the previous lesson; they are not proof of malicious intent or a complete response plan.

Trace It Yourself

Check: A support token is read-only and expires after ten minutes, but it can read metadata for every company document. What is still broad about its blast radius?

Think first, then reveal.

Answer: Its resource scope. The short lifetime and read-only action reduce some consequences, but a single use during the window can still reach many documents. The team should compare that access with the support case’s actual need.

Check: A team stores a service token in a vault but gives it thirty-day, company-wide authority. What question has the vault not answered?

Think first, then reveal.

Answer: What the capability can do after a legitimate system retrieves it: resource scope, lifetime, delegation, and revocation. Storage is one boundary, not the complete capability design.

Practice: Compare Two Expense-Tool Capabilities

A fictional expense service issues a token so finance support can inspect attachment metadata for one reimbursement case. Option A can read metadata for all reimbursements for seven days. Option B can read one named attachment for twenty minutes and becomes invalid when the case closes.

Build a capability map with scope, lifetime, delegation, revocation, evidence, and residual risk. Recommend one option for a confidential reimbursement attachment, and name the workflow cost it introduces. Do not design token formats or keys.

A good answer should mention:

• resource and action scope separately;
• why the case-bound option limits the reachable asset set and opportunity window;
• which identity or service may use each option;
• expiry or case closure as a containment boundary, not a guarantee;
• evidence connecting a use to the case and attachment;
• a legitimate support delay or exception path as the trade-off;
• a remaining risk, such as disclosure of the one attachment during the valid window.

Resources

• [ARTICLE] NIST SP 800-63B: Authenticators — Focus: distinguish authentication properties such as phishing and replay resistance from the authorization scope a system grants after sign-in.
• [ARTICLE] OWASP Authentication Cheat Sheet — Focus: compare authentication, re-authentication, and risk context without assuming they replace authorization boundaries.
• [FRAMEWORK] NIST Cybersecurity Framework 2.0 — Focus: connect bounded authority to protection, detection, response, recovery, and governance outcomes.
• [ARTICLE] MITRE ATT&CK: Get Started — Focus: use adversary behavior as a prompt for defensive questions, not as an instruction set.

Key Takeaways

• A secret or token is a capability; its scope, lifetime, delegation, and revocation determine its blast radius.
• Storage protects a capability before use, but does not by itself constrain what a valid capability can reach.
• Narrow resource scope and short lifetime reduce different parts of the path; neither is a complete defense alone.
• A capability map should show the accepted identity, reachable asset, stopping boundary, evidence, and residual risk.
• Design the smallest authority that completes the workflow, plus an accountable exception when it does not.