Role Trusts

role-trusts

role-trusts is the indirect-control command for identity review.

Use it when direct RBAC does not fully explain who really controls a principal, an application, or an access path.

What This Command Answers

• Which ownership, federation, or app-trust relationships matter here?
• Which identity can influence another one even without an obvious direct RBAC path?
• Which trust edge deserves immediate follow-up?

Run It

azurefox role-trusts --output table

For deeper correlation:

azurefox role-trusts --output json

Example Table Output

trust	source	target	confidence	operator signal	next review
federated-credential	build-app	build-sp	confirmed	Trust expansion visible; privilege confirmation next.	Check permissions for Azure control on build-sp.
service-principal-owner	automation-runner	build-sp	confirmed	Indirect control visible; ownership review next.	Review ownership around build-sp, then confirm Azure control in permissions.
app-owner	ci-admin@lab.local	build-app	confirmed	Indirect control visible; ownership review next.	Review ownership around build-app.

When To Use It

• when a principal looks important but raw RBAC does not explain why
• when app ownership or federated identity may be the real control path
• after Permissions or Privesc points to a principal that may be controlled indirectly

What To Look For

• app ownership that could let one identity influence a stronger app or principal
• federated trust relationships that cross an important boundary
• trust edges pointing toward already-privileged principals
• relationships that are easier to validate or act on than a noisier set of metadata links

Why It Matters

Not all real control shows up as a direct Azure role assignment.

In many environments, the deciding question is not just "who has access?" but "who can influence the identity that has access?" role-trusts helps you see those indirect control paths before they get buried under raw directory detail.

What Should Stand Out First

• trust edges that point toward already-powerful principals
• relationships that cross important boundaries such as tenant, app, or workload ownership
• edges that look more direct or easier to abuse than lower-signal metadata relationships
• both sides of the trust edge clearly enough to understand the path quickly

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

• If you see a graph-federated-credential row, go next to Permissions because it shows whether the target application or service principal already has Azure roles worth caring about.
• If you see a graph-owner edge into a service principal or application, go next to RBAC because it shows what Azure access that target identity actually has.

What To Do Next

• Use RBAC if you need to pair the trust edge with direct assignment evidence.
• Use Auth Policies if tenant-wide policy posture may make the trust edge easier to abuse.
• Escalate the interesting side of the trust edge into targeted follow-up instead of treating every app relationship as equally important.

Boundary

role-trusts should surface meaningful trust edges that change control.

It is not a generic directory graph dump or a replacement for broader cross-tenant analysis.