Chains Compute Control

chains compute-control

chains compute-control is the AzureFox family for direct compute-to-identity control pivots.

Use it when the important question is not just "which workload has an identity?" but "which token-capable compute foothold can already act as that identity and immediately widen Azure control?"

What This Command Gives You

• a stack-ranked queue of the strongest visible compute-to-control pivots
• one grouped row that ties together the compute foothold, token path, attached identity, and stronger Azure control
• faster separation between direct token-opportunity rows and broader compute posture
• a shorter path from tokens-credentials or workloads into the exact identity and permission validation that matters next

Run It

azurefox chains compute-control --output table

For saved structured output:

azurefox chains compute-control --output json

Example Table Output

priority	urgency	compute	path type	insertion point	visible azure control	confidence boundary	next review	note
high	pivot-now	vm-web-01	direct token opportunity	public IMDS token path	Owner across subscription-wide scope	AzureFox can name the token-capable compute foothold, the attached identity, and the stronger Azure control behind it from current scope.	Check vms for the host foothold, then permissions for exact scope on the attached identity.	VM 'vm-web-01' can request tokens as ua-app; that identity already maps to Owner across subscription-wide scope.

That row is intentionally narrow. The family is only meant to ship when AzureFox can already show the compute-side token path, the attached identity, and the stronger Azure consequence behind it.

When To Use It

• when tokens-credentials shows a managed-identity token surface and you want the shortest path to the Azure control that identity can reach
• when the compute foothold matters more than tenant-wide identity inventory
• when you need to know whether a workload should interrupt broader collection right now
• when you want the validating command immediately instead of manually joining workload, identity, and permission output

What To Look For

• path type first, because this family should stay limited to defended direct token opportunities
• insertion point, because that is the exact compute-side token path the operator should inspect next
• visible azure control, because that is the consequence that changes urgency
• confidence boundary, because the row should say clearly whether AzureFox can already name the foothold, attached identity, and stronger control
• next review, because the family exists to shorten the pivot into the validating flat commands
• the top rows first, because public or immediately reachable compute footholds should outrank softer paths

Why It Matters

Managed identities turn compute footholds into Azure control questions quickly.

The hard part is often not spotting that a workload has an identity. The hard part is deciding whether the workload can already mint tokens as that identity, whether the identity is attached cleanly enough to defend the join, and whether the resulting Azure control is strong enough to change what the operator does next.

chains compute-control matters because it shortens that decision. It surfaces only the rows where AzureFox can already defend the compute foothold, the token path, the attached identity, and the stronger Azure control in one place.

What Should Stand Out First

• direct token-opportunity rows first, because they already change the operator's next move
• publicly reachable or otherwise immediate footholds above softer internal-only review leads
• rows that already name one attached identity instead of mixed or ambiguous identity context
• rows whose stronger Azure control is plain and high consequence
• short, concrete confidence-boundary language instead of generic workload-risk wording

If the row cannot explain how the compute foothold requests tokens as the attached identity, it is not yet a strong compute-control row.

If You See..., Go Next To...

• If you see public IMDS token path, go next to VMs and Endpoints because those pages confirm the host foothold and ingress path behind the grouped row.
• If the row names an attached identity, go next to Managed-Identities because that page shows the exact identity attachment and scope context.
• If the row names stronger Azure control, go next to Permissions and RBAC because those pages confirm the exact role and scope boundary behind the pivot.
• If the compute foothold first surfaced in tokens-credentials, go next to Tokens-Credentials because that command owns the raw token-surface evidence behind the grouped story.

What server-side execution Means Here

When this family says a row still depends on server-side execution, AzureFox is saying something very specific in plain terms:

• the app is publicly reachable
• the app can ask Azure for a token as its managed identity
• but public reachability alone does not prove you can make the app do that on your behalf

In this context, server-side execution means things like:

• getting command or code execution inside the app container
• abusing an RCE-class bug
• exploiting a template or injection path that causes backend code to run
• finding an app feature that lets you trigger internal token-fetching behavior from the server side

It does not mean:

• simply visiting the public URL
• having a browser-side issue only
• AzureFox proving exploitation happened

That distinction matters because compute-control is a recon and path-prioritization family. It can show that a publicly reachable workload plus managed identity would be a meaningful pivot if the workload is executable on the server side, but it does not collapse that into proof that the operator or attacker already has that execution path.

What Counts As A Real Compute-Control Row

This family should stay strict about what makes a row worthy of grouped compute space:

• the compute foothold must already expose a token-capable path such as IMDS-backed token request
• AzureFox must be able to name the attached identity cleanly enough to defend the join
• the attached identity must already map to visible stronger Azure control
• mixed-identity or broader trust-expansion stories should stay out until AzureFox can explain the exact transform honestly

The v1 rule is simple: no defended token path, no compute-control row.

Why This Family Is Narrow On Purpose

This family is live, but it is intentionally narrow in v1.

It exists to catch the strongest direct compute-to-control pivots first. It is not meant to absorb generic credential findings, deployment stories, trust-expansion rows, or secret-bearing config paths just because they happen to involve a workload.

That narrow boundary is what keeps the grouped result useful. If the row is present, it should already look like a pivot-worthy compute foothold rather than a broad reminder that managed identities exist somewhere in the environment.

What To Do Next

• Start with the highest row that already names the compute foothold and attached identity clearly.
• Confirm the host foothold in the matching compute command before you spend time on weaker leads.
• Use Managed-Identities to validate the identity anchor.
• Use Permissions and RBAC to validate the stronger Azure control behind the row.
• Treat mixed-identity ambiguity as a stop sign, not a reason to guess.

Boundary

chains compute-control can claim a direct token opportunity only when AzureFox can show the compute-side token path, the attached identity, and the stronger Azure control behind that identity.

It cannot claim successful token minting, broaden the path into generic trust or credential stories, or hide uncertainty about which identity the workload is really using.