Lesson 9: Follow a Credential

Training overview · Lesson 9 of 11 · Previous: Leave what you don't know open · Next: Watch what gets into knowledge and memory

Goal

A credential is a chain: a foothold, a reach to where the credential sits, and what it opens.

After this lesson you can draw a credential where it really sits, read the three legs of its chain, and tell which facts about the key the team has to give you.

What you start from

Your model from lesson 8, or import L8-solution.zip.

The model refers to the lesson 7 control by name. If you import it, create that control first, as lesson 8 describes.

The team that runs the copilot gives it a code tool, so it can work through the logs and exports customers paste into their tickets. The tool runs in the copilot's own container.

The approval answer still holds. Lesson 6's answer, All Consequential Action Paths Require Approval, covers every consequential action the copilot takes, and running code is one. You ask the team, and they confirm that code runs wait for the same approval, so the answer stays true. A new tool reopens the answers it touches: ask again before you keep one given before the tool existed.

The recipe step

Step 7: Draw where each credential sits and what it opens

Draw each credential where it really sits: on the container or host that holds it, on every flow that presents it, and the store or service it opens at the end of that flow. A cloud role that a host's metadata endpoint serves sits on the host: draw the agent's container inside the host and the role on the host, with no arrow to the endpoint. Answer a credential's own facts (expiry, rotation, scope) and the host's metadata settings only as the team states them.

Why: A credential is a chain: an injected agent runs where a credential can be reached, takes it, and opens something with it. The analysis follows the chain through what you draw, and finds a metadata endpoint's role with no arrow drawn. A credential drawn in the wrong place, or not at all, hides the chain.

Ask:

• Which credentials sit where the agent runs: in its container, or on its host, served by the host's metadata endpoint?
• What does each credential open, and over which flow?
• Can the agent run code, or fetch an address it is given, where a credential can be reached?
• Is the host's metadata endpoint limited (IMDSv2, a hop limit), and does the agent's container share the host's PID, IPC or network namespace?
• Does the agent's approval answer still cover the tool it just gained?

Classes: Agent Credential, EC2 Instance, STS Temporary Credentials, Container.

What the analysis reads here:

• A cloud credential a host's metadata endpoint serves: STS Temporary Credentials, and 1 more in modules you may have installed.

Looks safe is the answer a guess would pick. Write it only when someone who knows has said so.

You drew the CRM API key the way this step asks in lesson 2: on Copilot container, which holds it, and on CRM lookup, which presents it. Since then the analysis has asked whether the copilot can read its container's files and environment. This lesson answers that question.

Steps

The team tells you the copilot now runs code. Record it:

1. On Support copilot, set Code Execution Tools Present (code_execution_tools_present, under Application Security) = true.

The field shows No from lesson 5, where the team said the copilot runs no code. Choose Yes.

Save the answer. The Attributes tab keeps your change until you click the save icon on the right of the panel. The icon has no label. A tab with unsaved changes shows a dot after its name.

Generate again.

What you should see

Findings: 3 systemic findings: 2 Confirmed · 1 Not ruled out.

Facts to establish: 3 questions.

Open questions on Not ruled out findings:

• Lethal trifecta at Ticket summariser:
  • Can an untrusted party read what reaches CRM?
  • Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
  • Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console

Model gaps: No gaps these patterns can detect; not an attestation of completeness.

A new finding appears: Credential chain at CRM API key, Confirmed. Its legs read foothold present, reach present, unlock present, and weak credential undetermined. The lethal trifectas at the copilot and at the summariser keep their states from lesson 8, and so do the summariser's three questions.

The two questions under Facts that could raise a finding in lesson 8 are gone. Both asked about a harness that reads files for an agent, which matters only to reach the CRM API key. The copilot now reaches the key itself, and the key now has a finding, so neither is asked.

What changed and why

The key's question became a finding. Expand the chain. It lists its paths, foothold → reach → unlock, and then each leg with its routes. Each required leg has one present route:

• foothold: the injected copilot. It reads untrusted content, from lesson 2, and now runs code.
• reach: its route reads "shared space of Copilot container". Code the copilot runs can read the container's files and environment, and the key sits in that environment.
• unlock: its route reads "CRM handles Customer records". Whoever holds the key can read the customer records.

All three required legs are present, so the chain is Confirmed.

Weak credential is undetermined. It is the chain's aggravating leg: it ranks the finding, but never decides it, so Facts to establish does not ask about it. The key's own facts settle it: whether it expires, whether it is rotated, and how far its scope reaches. Those are facts about the key, not the copilot, and only the team that issued it can give them. The exercise below answers them.

The summariser holds the same key. The chain also lists Ticket summariser as a foothold and a reach, both undetermined: the summariser's container holds the key too. One present route is enough for a leg, so those routes do not change the result and are not asked.

P gains a route. On the copilot's trifecta, the P leg now has a present shared space route for the CRM API key, on Copilot container. In lesson 2 this route was undetermined. The key is private data in its own right, and the copilot can now read it.

Draw your host. A credential sits where it is held, not where it is used. The key is used on CRM lookup, but it is held in the container's environment, and that is where an injected copilot finds it. Draw the holder first, then every flow that presents the credential, then what it opens at the end of that flow. A credential drawn in the wrong place, or not at all, hides the chain.

A sandbox is an answer the team gives. The class has a field for it, Code Execution Sandboxed (code_execution_sandboxed, under Application Security). Threat Patterns 0.1.6 and later read it. Stated sandboxed, the copilot's code reads nothing of its container, so the CRM API key's chain is not raised, unless something else reads the container. Answer it only when the team confirms four things: the sandbox mounts none of the copilot's files or working directory, receives none of its secrets or environment variables, holds no cloud or host credentials of its own, and its network cannot reach the cloud metadata endpoint or the copilot's own services. Never answer it as a guess: the chain disappears, and nothing on screen says it was a guess. The last exercise below shows what changes.

Exercise: The key's own facts

The team that issued the CRM API key confirms four facts about it: it expires, it is rotated, it is scoped to the CRM records the copilot needs, and it carries only the permissions the copilot needs.

These facts are on the key itself. Open the Data tab of CRM lookup and click the pencil icon on the key's row. The dialog reads Edit Data Entity. Go to its Attributes tab, answer as below, and save with the save icon at the bottom right of the dialog. It stays greyed out until something changes.

On a scratch copy: import L9-solution.zip and rename it.

1. On CRM API key, set:
   • Credential Expiry Enforced (credential_expiry_enforced, under Secrets & Credentials) = true
   • Key Rotation Enabled (key_rotation_enabled, under Secrets & Credentials) = true
   • Resource Scope Restricted (resource_scope_restricted, under Authorization & RBAC) = true
   • Permission Scope Minimized (permission_scope_minimized, under Authorization & RBAC) = true

Generate again.

Findings: 3 systemic findings: 2 Confirmed · 1 Not ruled out.

Facts to establish: 3 questions.

Open questions on Not ruled out findings:

• Lethal trifecta at Ticket summariser:
  • Can an untrusted party read what reaches CRM?
  • Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
  • Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console

Model gaps: No gaps these patterns can detect; not an attestation of completeness.

Weak credential goes absent, and the chain stays Confirmed. A well-kept key still sits where the injected copilot can take it, and it still opens the CRM. Weak credential is aggravating, so it never decided the finding. Only a changed fact that makes a required leg absent removes a chain, as in lesson 6.

Delete the copy when you are done.

Exercise: The cloud host

This exercise needs the AWS class modules AWS Compute & Containers (aws-compute-containers) and AWS Identity & Cryptography (aws-identity-cryptography) installed on your platform. Without them, the classes EC2 Instance and STS Temporary Credentials are not in the class picker. If they are missing, read the exercise and skip the drawing.

The team tells you more about where the copilot runs. Its container runs on an EC2 instance. An attachment service on the same instance stores the files customers attach to their tickets, and it uses the instance's role to write them to an attachment store. The copilot does not use the role.

On a scratch copy: import L9-solution.zip and rename it.

1. Add the boundary Copilot host (class EC2 Instance), inside Support network.
2. Add Attachment service (class Application Service), inside Copilot host.
3. Add Attachment store (class Object Storage), inside Support network.
4. Add the data item Copilot host role (class STS Temporary Credentials). Sensitivity: Restricted; Origin: Curated internal; Credential: Yes — a credential.
5. Add the data item Ticket attachments (class User Input). Sensitivity: Confidential; Origin: Arbitrary public; Credential: No.
6. Draw Store attachments (class HTTP/S Request) from Attachment service to Attachment store, and tick Copilot host role and Ticket attachments on its Data tab.
7. Attach Copilot host role to Copilot host.
8. Attach Ticket attachments to Attachment store.
9. Move Copilot container into Copilot host.

Moving the container into the host (step 9). A boundary nests in another only when you drop it fully inside a larger one. Drag a corner of Copilot host until it is larger than Copilot container on both sides. Then drag the container and drop it fully inside the host. To check, drag Copilot host a little: the container moves with it.

Draw no arrow to the instance's metadata endpoint. Generate again.

Findings: 4 systemic findings: 3 Confirmed · 1 Not ruled out.

Facts to establish: 3 questions.

Open questions on Not ruled out findings:

• Lethal trifecta at Ticket summariser:
  • Can an untrusted party read what reaches CRM?
  • Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
  • Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console

Model gaps: No gaps these patterns can detect; not an attestation of completeness.

A second chain appears: Credential chain at Copilot host role, Confirmed. Its legs read foothold present, reach present, unlock present, and weak credential undetermined. The CRM API key's chain is unchanged.

The analysis found the reach with no arrow drawn. The reach route reads "Copilot host role served by the credential endpoint of Copilot host". An EC2 instance serves its role to whatever on the instance asks its metadata endpoint for it, and the copilot has two ways to ask. Its code runs on the instance, inside its container, and can ask the endpoint directly. Its web fetch from lesson 4 can be pointed at the endpoint's address, and the role comes back into its context. That is the foothold route's basis: "untrusted input in the context the credential is returned into". The role lands beside the tickets and pages an attacker writes.

Taking the code tool away would not remove this reach. The web fetch still asks the endpoint.

The unlock follows the attachment service's flow. The unlock route reads "Attachment store handles Ticket attachments". The role opens the store because Store attachments carries it there. The copilot never uses the role, yet an injected copilot can take it and open the store.

Why the role sits on the host. The metadata endpoint belongs to the instance, and so does the role it serves. The role is in no file or environment variable of the copilot's container. Drawn inside the container, it would say the container holds it in a file or its environment, which is false. Drawn on Copilot host, with the container inside the host, it says what is true: anything running on the instance can ask for it.

Why there is no arrow to the endpoint. Nothing in the copilot calls the metadata endpoint. The reach is something an injected copilot could do, not traffic that happens. An arrow would draw a call that does not exist. Draw the role on the host and the container inside it, and the analysis finds the endpoint's reach from that.

The copilot's trifecta also gains a present shared space route on its P leg, for Copilot host role on Copilot host.

Keep this copy for the next exercise.

Exercise: The hop limit

You ask the platform team how the instance's metadata endpoint is set up. They confirm that the instance requires IMDSv2 with a hop limit of 1, and that the copilot's container shares none of the host's PID, IPC and network namespaces. The container's field claims all three, so the team has to confirm all three.

Double-click Copilot host and set the first answers on its Attributes tab. Set the namespace answer on Copilot container. Save each.

Continue on your copy from the exercise before.

1. On Copilot host, set:
   • IMDSv2 Required (imdsv2_required, under Authentication & Access) = true
   • IMDS PUT Response Hop Limit (imds_hop_limit, under Authentication & Access) = 1
2. On Copilot container, set Host PID/IPC/network namespaces not shared (container_host_namespaces_not_shared, under Host Isolation) = true.

Generate again.

Findings: 4 systemic findings: 2 Confirmed · 2 Not ruled out.

Facts to establish: 4 questions.

Open questions on Not ruled out findings:

• Lethal trifecta at Ticket summariser:
  • Can an untrusted party read what reaches CRM?
  • Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console
  • Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
• Credential chain at Copilot host role:
  • Is Copilot host role also kept on disk on Copilot host, where Support copilot can read it?

Model gaps: No gaps these patterns can detect; not an attestation of completeness.

The role's chain falls to Not ruled out: foothold present, reach undetermined, unlock present. The reach route now reads "shared space of Copilot host". The CRM API key's chain is still Confirmed.

The hop limit cut the endpoint's reach. With IMDSv2 and a hop limit of 1, the endpoint's token cannot travel the extra network hop from the container to the instance, so neither the copilot's code nor its web fetch can get the role from it. The container's answer matters as much as the hop limit: a hop limit of 1 stops a container one hop behind the host, not a process on the host itself, and a container that shares the host's network is not one hop behind.

One question stays. Under Open questions on Not ruled out findings, the chain asks: Is Copilot host role also kept on disk on Copilot host, where Support copilot can read it? The role may also sit in a file on the instance, for example in a host directory mounted into the copilot's container. Only the platform team can say. The question reads Credentials Materialized in Logs / Env (credentials_materialized_in_logs_or_env, under Secrets & Credentials) on Copilot host role. Answer it false only if the team confirms the role is never written to disk, to logs or to the environment. Otherwise leave the question open, and give it an owner and a date, as in lesson 8. Until it is settled, treat the reach as possible.

P still lists the role. The copilot's trifecta keeps its present shared space route for Copilot host role on Copilot host. P counts what sits in the copilot's space; the chain asks the sharper question of whether the copilot can read it.

Delete the copy when you are done.

Exercise: The sandbox

This exercise needs Threat Patterns 0.1.6 or later, because earlier versions do not read Code Execution Sandboxed.

The team confirms that the code tool runs in a sandbox that mounts none of the copilot's files or working directory, receives none of its secrets or environment variables, and holds no cloud or host credentials of its own. The sandbox's network cannot reach the cloud metadata endpoint or the copilot's own services. Double-click Support copilot, choose Yes for Code Execution Sandboxed on its Attributes tab, and save. The field shows only while Code Execution Tools Present is Yes, as it is since this lesson's step.

On a scratch copy: import L9-solution.zip and rename it.

1. On Support copilot, set Code Execution Sandboxed (code_execution_sandboxed, under Application Security) = true.

Generate again.

Findings: 2 systemic findings: 1 Confirmed · 1 Not ruled out.

Facts to establish: 5 questions.

Open questions on Not ruled out findings:

• Lethal trifecta at Ticket summariser:
  • Can an untrusted party read what reaches CRM?
  • Every drawn route from CRM ends inside; assert its outbound flows complete if nothing else leaves it
  • Draw the outbound flows of Staff console, or answer Markdown Image Rendering Policy (markdown_image_rendering_policy, in Output Rendering Exfiltration) on Staff console

Facts that could raise a finding:

• Draw the Agent Tool Call from Support copilot to the harness that reads files for it, if there is one (its code runs sandboxed)
• Draw the Agent Tool Call from Ticket summariser to the harness that reads files for it, if there is one

Model gaps: No gaps these patterns can detect; not an attestation of completeness.

The credential chain at the CRM API key is gone. The lethal trifectas at the copilot and at the summariser keep their states: the copilot's is still Confirmed, the summariser's still Not ruled out.

Sandboxed code reads nothing of the container. The chain's reach leg rested on the copilot's code reading Copilot container, where the key sits. Stated sandboxed, the code has no reach to the container, and nothing else drawn reads it, so no reach leg is present and no chain is raised.

The key's questions come back. With no finding on the key, the questions about it return under Facts that could raise a finding. The copilot's carries one addition: Draw the Agent Tool Call from Support copilot to the harness that reads files for it, if there is one (its code runs sandboxed). A sandbox stops the code, not a harness that reads files for the copilot. The summariser's question from lesson 8 returns beside it.

P loses the route. On the copilot's trifecta, the shared space route for the CRM API key on Copilot container goes back to undetermined, as it was in lesson 2.

Answer it only when the team confirms it. The chain was Confirmed, and one answer removed it. If the code can in fact read the container, an injected copilot can still take the key, and the model no longer shows it. A guessed sandbox hides a real chain.

Delete the copy when you are done.

Next

Lesson 10: Watch what gets into knowledge and memory. The copilot gains a knowledge base and a memory, and you draw how content gets into them.