Edge types

Physical/logical attachment. Semantic edges (ExecutesAs, HasPolicy) carry the security meaning.

Credential/identity authenticates to a service/endpoint (incl. SaaS/DB).

Source can add a principal (itself) to a group/role and inherit its permissions.

Full control (admin/owner) over a resource - implies most other capabilities on it.

Source can obtain the target identity's credentials/session (role assumption).

Derived summary: source effectively controls target (admin OR sufficient sub-capabilities).

Source can create new resources of a type within a scope.

Source can mint a NEW long-lived/short-lived credential for the target and thus authenticate as it.

Source can create keys (SA key creation overlaps CanCreateCredentialFor).

Source can create a new compute resource bound to target identity (create + pass identity).

Domain-wide/OAuth delegation to act for other principals.

Destructive; persistence/impact not escalation. Excluded from default paths. Produced by explicit normalization (delete-permission IAM actions) and by derived rules (evasion/cover-tracks primitives like disabling detective services).

Derived: source can become an identity with strictly greater privilege (rolls up an escalation chain).

Attacker-controlled code can run with the target identity's privileges. Canonical derived escalation edge.

External/workload identity is trusted to federate into a CSP identity (OIDC/SAML/Workload Identity).

Source can assign a role/permission to a principal (incl. itself) - privilege escalation primitive.

Source acts as target without holding long-lived creds (GCP SA impersonation, act-on-behalf-of).

General modify capability (specialized by CanModifyCode/Configuration/Policy where meaningful). Produced by explicit normalization (modify permissions) and derived rules (config-modification attack paths like CloudTrail tampering, logging-service disablement).

Source can change config (env vars, layers, startup command, identity binding) to gain execution or escalate. Produced by explicit normalization (control-plane config-update permissions) and by derived rules (trigger hijacking, notification redirection).

Source can alter an identity/resource policy to grant itself/others more access. Produced both by explicit normalization (IAM/RBAC setPolicy grants) and by derived rules (deny-policy/org-policy modify capabilities that unlock gated edges).

Source can rewrite who may assume/impersonate the target - self-grant assumption.

Source may attach/pass the target identity to a NEW or existing workload (prereq for CanExecuteAs).

Read configuration/metadata of a resource (recon; low base value). Produced by explicit normalization (configuration-read IAM permissions) and by derived rules (recon primitives like reading Macie findings to identify sensitive-data targets).

Membership removal - mostly destructive/persistence, not escalation; not walked by default.

Delete+recreate to inherit name/identity/trust (config-drift escalation).

Source can reset/replace target's password/MFA and take over.

Source can obtain an access/OIDC token for an identity (metadata endpoint, token mint).

Source can sign tokens/blobs as the target (JWT/SAML signing -> forge identity).

Source can become owner (Azure SP/app owner, resource owner) and thereby self-grant control.

Modify a resource's configuration. Produced by explicit normalization (write permissions) and derived rules (config-write attack paths).

Terminal control edge: source can administer the target boundary/resource (objective attainment).

A trust/resource policy names a principal in another account (feeds CanAssume/CanEnterAccount). Produced by explicit normalization (policy artifact parsing) and by derived rules (cross-account data-resource sharing patterns like S3 bucket policy with foreign principal). Subscription targets cover Azure's account-boundary analog - a cross-subscription trust (e.g. an approved cross-subscription Private Endpoint connection, or cross-subscription VNet peering).

Cross-project IAM binding / SA usage. ServiceAccount targets cover a workload in one project running as (trusting) a service account owned by another project (e.g. a Vertex AI job or Workbench instance with a cross-project runtime SA) - symmetric with ServiceAccount as a source.

B2B/guest/multi-tenant app trust across Entra tenants.

An external/workload identity resolves to a concrete internal principal (guest->member, IdP subject->role, k8s SA->IAM role).

Identity in provider A is trusted to obtain an identity in provider B (OIDC/SAML/WIF). Enables cross-cloud paths.

EFFECTIVE permission (post evaluation) of an action on a target. Produced by the permission engine / effective-permission evaluator.

Principal is directly granted a role (Entra role, GCP role binding, IAM role attachment).

Source inherits the target's permissions via membership.

Target trusts an external/federated/workload principal - inbound cross-boundary access (incl. k8s IRSA/WI federation). Source can be an identity (principal), a resource policy, or a policy document (e.g., B2C trust policy) that declares the trust.