Identity & Security

Two questions that people constantly merge into one, and that every cloud keeps rigorously separate.

Authentication (authN) is "who are you, and can you prove it?". Showing your passport at the airport check-in desk. The outcome is an established identity, or a rejection.

Authorization (authZ) is "given that I now know who you are, are you allowed to do this particular thing?". The boarding pass that gets you onto this flight, in this seat. The passport proved identity; it said nothing about which plane.

The distinction earns its keep because the two fail differently and are fixed differently. "Access denied" after a successful login is an authZ problem — adding another factor to your login will not help. Conversely, a stolen password is an authN problem, and no amount of careful permission design fixes it.

Every cloud API call runs the same five stages. The vendors differ in the names of the components, not the sequence. Step through it:

• Some controls straddle both. Azure Conditional Access evaluates at authentication time but decides using authorization-shaped inputs (device compliance, risk score, location). It is best read as "authN with policy", and it is why Azure's identity story feels different from the other two.
• Successful authN is not nothing. Even with zero permissions, an authenticated principal has proven a credential is valid, can often enumerate error messages, and exists in your audit trail. Attackers value a valid low-privilege identity precisely because it is a foothold to escalate from.
• Authorization is stateless per request. There is no session that "stays" authorized. Every call is re-evaluated against current policy. Revoke a role binding and the next call fails — though a token already issued may remain valid until it expires, typically minutes to an hour. That gap is real and worth knowing during an incident.
• The third question. Mature systems ask accounting too — what did the principal actually do? AuthN, authZ and audit together are sometimes called AAA. Skipping the third makes the first two unverifiable.

"User" is the most misleading word in cloud security, because the overwhelming majority of principals in any real environment are not users. They are programs.

Think of a hospital. Some badges belong to people — a doctor swipes in, and the badge is tied to a human who can be trained, fired, and asked to prove who they are with a second factor. Other badges belong to machines — the pharmacy robot, the lab analyser. Nobody phones the robot to check it is really the robot; it authenticates constantly, silently, and nobody watches. And recently a third kind appeared: the badge for something that acts on behalf of a person but makes its own decisions about what to do next.

The single most useful habit in this stage: whenever you read "identity", immediately ask which kind. Half of all bad cloud security advice comes from applying human-identity controls to workloads, or vice versa. Telling a service account to enable MFA is not a hardening step; it is a category error.

Workload identities outnumber human ones by a wide margin in any container or data platform, and they behave worse: they are created by pipelines, rarely reviewed, and frequently granted broad permissions "temporarily" so a deployment will go green. Two current figures put numbers on it:

• Orca's 2025 cloud security research found 78% of organizations have at least one IAM role that has not been used in over 90 days — standing, unused, still grantable.
• A 2026 infrastructure identity survey reported that 70% of organizations grant AI systems more access than they would give a human employee doing the same job. That is the agent-identity problem in one sentence, and it is the reason the vendors built a distinct construct for it.

Orca Security research, cited in orca.security · 2026 Infrastructure Identity Survey, cited by NHI Management Group.

Once you know who is asking, you need a way to write down what they may do. There are three broad grammars, and every cloud uses some blend of them.

RBAC — role-based. "Nurses may read charts." You define a job, attach permissions to it, and assign people to the job. Like a job title in an org chart: what you may do follows from what you are.

ABAC — attribute-based. "Anyone whose department matches the record's department may read it." No named role — a rule compares properties of the principal, the resource and the context. Like a rule that says you may enter any room whose colour matches your badge.

Policy-based. The general case, and what the clouds actually implement: a document that states allow-or-deny over (principals, actions, resources) with optional conditions. RBAC and ABAC both fall out of it — a role is a named bundle of policy, a condition block is where attributes go.

Every cloud's grant, stripped to its skeleton, is the same shape. Here is that shape in pseudo-syntax, with each part labelled by the triangle vertex it belongs to:

# --- the universal grant ---
effect:     allow | deny            # the verdict
principal:  who this applies to     # WHO   (often implied by attachment)
action:     what may be done        # the verb
resource:   on which thing          # WHAT  (often implied by attachment)
condition:  ...only when this holds # ABAC lives here

The clouds differ mainly in which fields are implied by where you attach the document. Attach it to a principal and the principal field is redundant. Attach it to a resource and the resource field is redundant. Azure goes furthest — a role assignment names the principal, the role definition and the scope, and derives everything else. That single insight makes all three dialects readable.

The practical answer everywhere is a hybrid: RBAC for the coarse grain, ABAC for the fine grain. Roles decide what kind of thing you may do; conditions decide which instances. The failure mode to avoid is using ABAC as a patch over a role you were afraid to scope down — the condition becomes the only thing standing between a broad grant and a broad breach, and conditions are much easier to get subtly wrong than role assignments.

Least privilege is a one-line idea: every principal gets exactly the permissions it needs for its task, and nothing more, for no longer than it needs them.

It is trivially agreeable and almost never achieved, for a reason worth stating plainly: permissions are asymmetric. Granting one takes seconds and unblocks somebody who is currently blocked. Removing one takes research, risks breaking something at 3am, and unblocks nobody. So the ratchet only turns one way.

The accumulated result has a name. Privilege creep: the slow, undirected growth of what an identity can do, well past what it does. It arrives through three doors — the wildcard, the inherited role, and the temporary grant that was never temporary.

The reason least privilege is a security control and not just hygiene is blast radius: the set of things an attacker reaches once they hold a credential. Least privilege does not reduce the chance of compromise. It reduces what compromise costs.

The countermeasure is measurement, not intention. "We will be careful" fails predictably. What works is a feedback loop: log every authorization decision, compare granted permissions to used permissions over a window, and remove the difference. Every cloud now ships this — AWS IAM Access Analyzer's unused-access findings, Entra Permissions Management, GCP's IAM Recommender. The tooling finds the gap; closing it is still a human decision, and that remains the bottleneck.

Federation is a system agreeing to accept identity claims issued by a system it does not control.

The everyday analogy is a passport. A hotel in Tokyo does not maintain a database of Irish citizens. It accepts a passport because it trusts the Irish government's issuing process — the tamper-evident document, the known format, the verifiable signature. The hotel authenticates the document, and thereby, at one remove, the person.

Two roles matter. The identity provider (IdP) issues claims — the passport office. The relying party or service provider consumes them — the hotel. The trust is configured once, deliberately, and then every subsequent login rides on it.

Single sign-on (SSO) is the user-visible consequence: authenticate once to the IdP, and every relying party that trusts it lets you in without a separate password. SSO is the feature; federation is the plumbing.

This exact five-step dance underlies corporate SSO, GitHub Actions deploying to a cloud, and a Kubernetes pod getting cloud credentials. Learn it once here and you will recognise it in all three clouds:

• The subject pattern is the whole boundary. Trusting an issuer without constraining the subject is the single most dangerous federation misconfiguration, and it is easy to make because the broad version works perfectly in testing.
• Trust is transitive whether you like it or not. If you federate with an IdP, then whoever administers that IdP can mint an identity that your cloud accepts. Federating with a partner means inheriting their offboarding discipline.
• Token lifetime is a real trade-off. Short tokens shrink the window a stolen one is useful, and increase load on the token service and the blast radius of an outage in it. Fifteen minutes to one hour is the common range for workloads.
• Revocation is weak by design. A signed token is valid until it expires; there is no central "cancel". You revoke the underlying grant so the next exchange fails. Plan incident response around that lag rather than being surprised by it.
• Clock skew breaks things silently. Tokens carry not-before and expiry claims. A host whose clock drifts by minutes produces authentication failures that look like permission problems and waste hours.

That open problem has a name in practice: secret zero. You can move every credential into a vault, and you are still left with one credential — the one that opens the vault. Move that into a second vault and you have moved the problem, not solved it.

The modern answer is not a better hiding place. It is to stop having a secret zero at all.

Here is the shift, in one line. A secret is something you know. An identity is something you are. A password can be copied by anyone who sees it, and remains valid wherever it is used. But the platform that started your container already knows, with certainty, which container it started — it allocated the process. Workload identity is the platform attesting to that fact, cryptographically, so the container never needs to know a password in the first place.

The analogy: a door code is a secret — whoever overhears it gets in, forever. Your face is an identity — it cannot be handed to a colleague, and it is verified fresh each time.

This move is not in the patterns catalog, so I am teaching it from first principles rather than attributing it. Brown's framing is still exactly right about why configuration must be external; the platforms simply grew a better answer to how after the pattern was written.

Every cloud implements the same three-part trick, and it is worth seeing the shape before you see the vendor names in the next three tabs:

1. The platform attests. The hypervisor, orchestrator or runtime knows which workload it launched and will vouch for it.
2. The workload asks locally. It calls a link-local metadata endpoint — unroutable, reachable only from inside that instance — and asks for a token. No credential is presented, because the ability to make the call from that network position is the credential.
3. A short-lived token comes back, scoped to whatever identity was attached at deployment time, and the SDK refreshes it automatically before it expires.

Secrets do not disappear; they get demoted. Vaults remain the right home for the things that are irreducibly secrets — third-party API keys, database passwords for engines that only speak passwords, signing keys. But the credential your workload uses to open the vault becomes a platform identity, and secret zero stops existing.

• Crossing a trust boundary the platform cannot attest to — a third-party SaaS API that has never heard of your cloud. Unless it supports OIDC federation, you hold a key.
• Legacy protocols. Database engines, SMTP, message brokers that only understand a username and password. Cloud databases increasingly accept platform identity; older engines do not.
• Signing material. A private key for signing artefacts is a secret by definition. It belongs in a key-management service that performs the signing internally so the key never leaves.
• The escalating hierarchy. Preference order, best first: platform-attested identity → federated token from a trusted issuer → short-lived secret from a vault, fetched with a platform identity → long-lived secret in a vault → long-lived secret in an environment variable → secret in source control. Every step down multiplies both the time a leak stays useful and the number of people who can cause one.

Three nouns, and the interesting one is the third.

An IAM user is a permanent identity with permanent credentials — a password, or an access key pair that works until someone deletes it. It is a named employee badge that never expires.

An IAM group is a bag of users that carries policies. It is purely an administrative convenience: groups are not principals, nothing "runs as" a group, and you cannot grant a group access to anything the way you would grant a role.

An IAM role is the one that does not exist in ordinary life. A role is an identity nobody owns. It has permissions but no permanent credentials. Instead, it has a second document — a trust policy — saying who is permitted to become it. When someone qualifies, they receive temporary credentials that expire.

The analogy that works: a role is a hi-vis vest hanging by the door of a construction site. The vest is not anybody's. It confers the right to be on site. The rule on the wall — "site staff and their contractors may wear this" — is the trust policy. You put it on, do the job, and hang it back up.

Why this matters more than it sounds: because a role's credentials expire, an attacker who steals them holds something with a clock on it. Because a user's access key does not expire, an attacker who steals that holds something permanent. This single property is why current AWS guidance is to create essentially no IAM users at all.

Every role carries two policy documents doing completely different jobs, and conflating them is the most common beginner error on AWS.

{
  "Effect": "Allow",
  "Principal": {
    "Service": "ec2.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource":
    "arn:aws:s3:::weights/gemma-2b/*"
}

Access denied on AssumeRole is a trust-policy problem. Access denied after assuming is a permissions-policy problem. That one sentence resolves a large fraction of AWS IAM confusion, and it is worth memorising before you touch a console.

• Default quotas per account (several are adjustable): 5,000 IAM users, 300 groups, 1,000 roles, 1,500 customer-managed policies. A user may belong to 10 groups and carry 10 attached managed policies. A managed policy document is capped at 6,144 characters — small enough that real least-privilege policies routinely hit it, which is itself an argument for ABAC conditions over enumerating resources.
• Two access keys per user, maximum. That limit exists to make rotation possible: create the second, migrate, delete the first. If you have users at all, this is the drill.
• The current answer to "how do humans log in?" is not IAM users. It is IAM Identity Center — AWS's SSO service, formerly AWS SSO — or federation from your own identity provider. Both issue short-lived role sessions instead of permanent keys. A greenfield AWS environment in 2026 should contain zero IAM users with console passwords.
• Roles are cheap. Create more of them. The instinct to reuse one role across several workloads is exactly the mechanism that produced the "one permissive role on fifty instances" figure from Session 1. A role per workload costs nothing and bounds each blast radius separately.

An AWS policy is a list of sentences. Each sentence says: allow or deny — these verbs — on these nouns — optionally only when some fact about the request holds. That is the entire grammar. Everything else is vocabulary.

{
  "Version": "2012-10-17",              // always this date; it is a language version, not a timestamp
  "Statement": [{
    "Sid": "ReadGemmaWeightsOnly",      // your label. Show up in denials. Name them well.
    "Effect": "Allow",                  // Allow | Deny
    "Action": "s3:GetObject",           // service:Operation. Wildcards legal, hence dangerous.
    "Resource": "arn:aws:s3:::weights/gemma-2b/*",
    "Condition": {                      // where ABAC lives
      "StringEquals": { "aws:PrincipalTag/team": "inference" }
    }
  }]
}

Three details that repay attention:

• The ARN is the resource half of the triangle, and it is structured: arn:partition:service:region:account-id:resource. Empty segments are meaningful — S3 ARNs carry no region or account because bucket names are globally unique. Getting an ARN subtly wrong produces a silent denial, never an error.
• Resource is absent from trust policies and present in identity policies; Principal is the reverse. If you find yourself writing both in one statement, you are probably writing a resource-based policy — which is fine, but know which one you are writing.
• The condition block is where least privilege becomes affordable. Enumerating a thousand ARNs blows the 6,144-character limit; one condition on a tag does not. This is why ABAC is not a nicety on AWS but a scaling necessity.

The skill worth building is not writing policies but reading them for what they permit beyond their stated purpose. A checklist:

• Wildcards in Action. s3:* includes DeleteBucket and PutBucketPolicy — the second lets the holder grant access to anyone. iam:* is account takeover written in six characters.
• The escalation actions specifically. iam:PassRole, iam:CreatePolicyVersion, iam:AttachUserPolicy, sts:AssumeRole with a loose resource, and lambda:CreateFunction combined with PassRole. Each is a path from limited permissions to unlimited ones, and none of them looks alarming in isolation.
• NotAction and NotResource. Legal, occasionally necessary, and inverted logic that humans reliably misread. Treat their presence as a prompt to slow down.
• Conditions that do not constrain what you think. aws:SourceIp does nothing against a request routed through a VPC endpoint; you want aws:SourceVpce. A condition that never matches fails closed and is merely annoying; one that always matches fails open and is a vulnerability.

Two attachment points, and the rules for combining them are not symmetric — which surprises people.

• Same account: either one can grant. An allow in the identity policy is enough; an allow in the resource policy is enough. You do not need both.
• Cross-account: you need both. The resource's account must allow your principal, and your account must allow the principal to make the call. Two teams have to agree, deliberately. This is a feature, and it is the mechanism behind almost all safe cross-account sharing.
• The short-circuit worth knowing: if a resource-based policy grants access directly to an IAM user or a role session principal, an implicit deny in a permissions boundary or session policy does not block it. That asymmetry exists for good reasons and it is exactly the kind of thing that makes a boundary less absolute than its name suggests.
• KMS is the one to watch. A KMS key policy is unusual in that it must explicitly delegate to IAM before identity policies have any effect on the key at all. Encrypt something with a key whose policy you then break and you can lock yourself out of your own data permanently — one of the few genuinely unrecoverable mistakes on AWS.

AWS Security Token Service (STS) is the component that mints temporary credentials. The material covers it heavily in §3 and it is worth the attention — STS is the beating heart of AWS identity, and nearly every modern AWS credential passes through it.

A permissions boundary is a policy that defines the maximum a principal can ever have, regardless of what anyone grants it later. It grants nothing by itself.

The analogy: a spending limit on a corporate card. Your manager can approve any expense they like; the card still declines above the limit. The limit does not authorise a single purchase — it only caps them.

The reason it exists is safe delegation. You want to let a team lead create roles for their own team without being able to create a role with administrator access. Give the lead permission to create roles, but require that every role they create carries a specific boundary. They get autonomy; the ceiling holds.

Effective permissions are the intersection of the identity policy and the boundary:

Identity policy grants:  s3:*        ec2:*      iam:*
Boundary permits:        s3:*        ec2:Describe*
                         ────────    ──────────    ───
Effective:               s3:*        ec2:Describe*  (nothing)

Both must allow. Neither alone suffices. Adding a boundary to an existing principal reduces what it can do; removing one increases it — which is why boundaries are usually enforced by an SCP requiring that they be attached, rather than by trusting people to attach them.

Both are ceilings; the difference is who holds the ladder. A boundary is a local ceiling an account admin controls. An SCP is a ceiling imposed from outside the account, which is precisely why it is the right tool for "no one in the sandbox OU may leave the EU region" and the wrong tool for "this one role should not grow".

SCPs and RCPs are both org-wide ceilings, and the difference between them is which vertex of the triangle they cap.

SCP caps the principal. "Nobody in this organization may do X." It follows the actor.

RCP caps the resource. "Nothing may be done to my resources by anyone outside this organization, whatever their own permissions say." It follows the thing.

Why the second one had to exist: before RCPs, an org administrator could constrain their own people perfectly, and still have a bucket policy in some member account granting a stranger read access. The SCP never saw that request, because the requester was not their principal. RCPs close that hole from the resource side — which is exactly what AWS means by a data perimeter.

• Both attach to the org root, an OU, or an account — the C1 hierarchy, reused. Both inherit downward and cannot be escaped by the account's own administrator.
• Both are filters, not grants. An SCP that allows an action grants nothing; it merely declines to remove it. You still need an identity policy. This is the number-one SCP misconception.
• Both ship with a default full-access managed policy attached everywhere — FullAWSAccess for SCPs and RCPFullAWSAccess for RCPs — which cannot be detached and exists so that enabling the feature changes nothing until you write your first real policy.
• The management account is exempt from SCPs. Every guardrail you write has a hole in the shape of that account, which is why the standing advice is to run no workloads in it.
• RCPs currently apply to a specific and growing service list — S3, STS, KMS, SQS and Secrets Manager at launch, with Cognito and CloudWatch Logs added in January 2026 and DynamoDB in February 2026. Check the current list before assuming coverage; a data perimeter with a gap is not one.

A third type exists that is neither: declarative policies enforce a desired configuration at the service control plane rather than gating an API call. Attach one and the configuration is maintained even as the service adds new features and APIs later — the "block public access on EC2 AMIs, forever, including for features that do not exist yet" case. Also in the family: backup policies, tag policies, chat-application policies, AI services opt-out policies, and Security Hub policies.

• The RCP quota doubled to 2,000 per organization in July 2026, from 1,000, at no extra cost and with no action required. If you read anything citing the old limit, it is out of date.
• SCPs gained the full IAM policy language in 2025, including condition keys and NotAction. Older guidance describing SCPs as a restricted subset is stale.
• Test SCPs on an OU containing one throwaway account. An SCP applied at the root that denies something load-bearing takes effect immediately across every account, and the people best placed to fix it may be the ones you just locked out.
• Deny-lists scale, allow-lists do not. An SCP that lists permitted services must be updated every time anyone adopts a new one, and that update becomes a bottleneck the whole org routes around. Denying specific dangerous things ages far better.

AWS Organizations policy types — docs.aws.amazon.com · RCP launch — aws.amazon.com · quota increase — aws.amazon.com.

Three mechanisms, all producing the same outcome — short-lived STS credentials with no stored secret — and differing in how the trust is established.

Why Pod Identity exists, concretely. With IRSA, every IAM role a pod can assume must carry the cluster's OIDC issuer URL in its trust policy. Five clusters means five trust statements per role; adding a cluster means editing every relevant role; and at scale you hit both the per-account OIDC provider limit and the trust-policy size limit, which forces people to duplicate roles. Cluster admins also often lack the IAM permissions to create OIDC providers, so every change becomes a cross-team ticket.

Pod Identity also does something IRSA cannot: it injects session tags automatically — cluster ARN, cluster name, namespace, service account, pod name — which are usable in policy conditions via aws:PrincipalTag. That makes real ABAC on Kubernetes workloads practical for the first time: one role, conditioned on namespace, instead of a role per namespace.

Entra's object model is unusual, and it is worth getting straight before anything else because the names are genuinely counter-intuitive.

An application registration is the definition of an application — its blueprint. It lives in the tenant where the application was authored, and it says what the app is, what permissions it wants, and how it authenticates.

A service principal is the local instance of that application in a particular tenant — the thing that actually gets permissions and signs in. One registration can have service principals in many tenants; that is how multi-tenant SaaS works.

The analogy: the registration is the recipe, the service principal is the meal on your table. You grant permissions to the meal, not the recipe.

This matters because every non-human identity in Azure is ultimately a service principal. Managed identities are service principals with the credential handling removed. And as of 2026, the new agent identities are also built on the service principal object — Microsoft extended the most elastic object in the directory rather than inventing a new primitive.

Where AWS writes a JSON document, Azure composes a role assignment from three parts. That is the whole model:

# role assignment = WHO + WHAT + WHERE
az role assignment create \
  --assignee      <object-id of user, group, SP or managed identity>   # WHO
  --role          "Storage Blob Data Reader"                            # WHAT (role definition)
  --scope         "/subscriptions/<sub>/resourceGroups/rg-inference/providers/Microsoft.Storage/storageAccounts/weights"

Compare with AWS. The action lives in the role definition (a named, reusable bundle). The resource is not written at all — it is implied by the scope. That is why Azure has almost no resource-based policies: the scope of the assignment already answers "on what".

Scope is a path down the C1 hierarchy, and assignments inherit downward and accumulate. An assignment at a management group applies to every subscription beneath it. Effective permissions are the union of every assignment at every level above the resource — which is why an unexpected permission usually turns out to have been granted three levels up by someone else.

• Additive by default. Like GCP and unlike AWS, ordinary Azure RBAC has no "deny" you can write. More assignments only ever mean more access. You reduce access by removing assignments or by assigning at a narrower scope — not by adding a restriction.
• Deny assignments exist but you mostly cannot create them. They are primarily generated by Azure Blueprints and Managed Applications. Treat them as something you will encounter and be confused by, not something you will sources. When a subscription Owner cannot delete a resource, a deny assignment is usually why.
• ABAC conditions are the supported way to narrow a broad role — for example, granting Storage Blob Data Reader but only for blobs carrying a particular index tag. Support is real but not universal across services; check per service before designing around it.
• Quotas that bite at scale: roughly 4,000 role assignments per subscription and 5,000 per management group, and 5,000 custom role definitions per tenant. Groups are the escape hatch — assign to a group once rather than to two hundred users — and the sooner you adopt that habit the less painful the migration.
• Control plane and data plane are separate grants. Contributor on a storage account lets you manage the account and, notably, read its access keys — but the clean way to read a blob is the Storage Blob Data Reader data-plane role. Any role name containing "Data" is a data-plane role, and that naming convention is one of the more useful things to memorise.

A managed identity is a service principal that Azure creates, credentials, rotates and deletes on your behalf. You never see a secret because there is never a secret for you to see. It is the direct answer to Session 1's secret-zero problem, and it is the single most important thing in this session for your work.

Two flavours, and the choice is more consequential than it looks:

Identical in shape to the AWS instance profile and the GCP attached service account, which is the point:

1. You enable a managed identity on a resource — VM, App Service, Function, AKS pod, Container App. Azure creates the service principal in Entra.
2. You give that principal role assignments at the scopes it needs.
3. At runtime the code calls the Instance Metadata Service at 169.254.169.254 (or an injected local endpoint) and receives an access token for the target resource. The Azure SDK's DefaultAzureCredential does this automatically, which is why correctly written Azure code often contains no credential handling at all.
4. Tokens are short-lived and refreshed transparently.

Managed identities only work for compute inside Azure. For everything else — GitHub Actions, a workload on GCP or AWS, an on-prem Kubernetes cluster — Azure offers workload identity federation: configure a federated credential on a user-assigned managed identity or app registration, naming the external issuer, subject and audience, and the external token is exchanged for an Entra token. Same three-constraint model as Session 1; same warning about subject patterns.

For AKS specifically this is Microsoft Entra Workload ID: the cluster acts as an OIDC issuer, a Kubernetes service account is annotated with a client ID, and the pod's projected token is exchanged for an Entra token. It replaced the older pod-identity approach, which worked by intercepting metadata traffic — a design that had the same drawbacks as AWS's pre-IRSA world. If you know IRSA, you already know this.

Microsoft Learn, Workload identities — learn.microsoft.com.

Microsoft Entra Agent ID is now generally available and makes AI agents a first-class identity type alongside human users and workload identities. Given your work, this is worth knowing about even if you never touch Azure in production — it is the clearest statement yet of how a major vendor thinks agent identity should work.

The distinction Microsoft draws is worth repeating because it is the substantive argument, not marketing: application identities were designed for services with long-term stability, known ownership and a managed lifecycle. Agents are created and destroyed quickly, act autonomously, and make dynamic decisions about which tools to call — so their permission needs cannot be fully known at design time. There are also Conditional Access templates specifically for blocking high-risk agent identities and for autonomous agents operating without user context.

Two practical notes. It supports OAuth 2.0, MCP and A2A, and works with agents built elsewhere — including on AWS Bedrock — via an auth SDK sidecar or workload identity federation. And the full governance product around it, Microsoft Agent 365, is separately licensed, so "Agent ID" and "the whole agent governance suite" are not the same purchase.

Microsoft Learn, What is Microsoft Entra Agent ID? — learn.microsoft.com.

Conditional Access is Azure's answer to "authentication should not be a single yes/no". It is an if-then engine evaluated at sign-in: if these signals hold, then require these controls or block.

It is the piece with no clean AWS equivalent, and the reason Azure's identity story feels different. AWS decides authorization from policy documents about actions and resources; Azure additionally decides authentication strength from context — who, from where, on what device, how risky does this look.

Every policy is signals → decision:

The break-glass rule. Always exclude at least two emergency-access accounts from every Conditional Access policy, store their credentials offline, and monitor their use. A policy requiring a compliant device, authored on a non-compliant device, locks the material out of the tenant that would let them fix it. This is the single most common self-inflicted Azure outage and it is entirely avoidable.

Privileged Identity Management (PIM) is the companion control and the one the material does cover. It makes privileged roles eligible rather than active: you hold no standing permission, you activate for a bounded window with justification, approval and MFA, and it expires on its own. This is the structural fix for the "permanent temporary" privilege-creep door from Session 1 — the grant expires without anyone remembering to remove it. It works for both Entra roles and Azure RBAC roles, and it requires Entra ID P2 licensing.

Azure Key Vault stores three kinds of thing, and the distinction matters: secrets (arbitrary strings — passwords, connection strings, API keys), keys (cryptographic keys, where the vault performs sign, verify, wrap and unwrap operations internally so the key never leaves), and certificates.

The intended pattern is the one you now recognise: the application holds no secrets, authenticates with its managed identity, and fetches what it needs at runtime. Key Vault plus managed identity is the Azure answer to secret zero.

The security argument for the change is not cosmetic, and it is the subject of this session's worked example below. Under the access-policy model, anyone holding a role with Microsoft.KeyVault/vaults/write — which includes plain Contributor — can edit the vault's access policy list and thereby grant themselves data-plane access to every secret in it. Under RBAC, permission management is restricted to Owner and User Access Administrator, so managing the vault and reading its contents are genuinely separate privileges.

The last big Azure distinction, and the one that maps least cleanly onto AWS.

The capability that has no AWS analogue is that Azure Policy does not only refuse. Its effects include deny, audit, modify (silently fix the request as it passes) and deployIfNotExists (create a missing companion resource, such as attaching diagnostic settings to every new resource automatically). An SCP can only subtract; Azure Policy can subtract, correct and add. That makes it the natural home for "every storage account must have secure transfer on" — and, aptly, it is the mechanism Microsoft used to roll out mandatory MFA enforcement.

Where they meet: both attach at management group, subscription or resource group scope and inherit downward. A policy at a management group is Azure's closest structural equivalent to an AWS SCP, with the important caveat that a subscription Owner can usually create an exemption, whereas an SCP cannot be escaped from inside the account.

Three nouns, and Google's vocabulary is the most consistent of the three clouds once you accept one historical wrinkle: what the docs now call a principal was called a member until recently, and your source uses both.

A principal is anything that can be named in a policy: a Google Account, a Google group, a whole domain, a service account, an agent identity, or one of two special values — allAuthenticatedUsers and allUsers. That last pair deserves a moment of alarm: allUsers means literally the entire internet, unauthenticated, and it is one dropdown selection away in the console.

A role is a named bundle of permissions. You never grant a permission directly on GCP — you grant a role that contains it. Permissions are named service.resource.verb, as in storage.objects.get.

A binding joins them: this role, to these principals, attached at this node. The set of bindings on a node is that node's allow policy.

# a binding, in the shape gcloud and Terraform both use
gcloud projects add-iam-policy-binding ml-serving \
  --member="serviceAccount:vllm-inference@ml-serving.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/weights/objects/gemma-2b/"),title=gemma-only'

Note where the resource lives. There is no resource field — the binding is attached to the project, so every bucket in it is in scope. Narrowing to one prefix requires the condition, written in Common Expression Language. On GCP, conditions are not an optimisation; they are frequently the only way to express least privilege at all.

• Roles are additive within a principal too. Holding both roles/viewer and roles/storage.admin gives you the union. There is no "most specific wins".
• Groups count more than once. For the allow-policy principal limit, each appearance of a group in a binding counts separately — so a heavily used group consumes quota faster than expected.
• Conditions do not work everywhere. Not all services support all condition attributes, and an unsupported condition can behave differently from how it reads. Test rather than assume.
• Predefined roles drift. Because Google maintains them, a role can gain permissions between audits. This is a genuine argument for periodic re-review rather than one-time design.
• Two roles are escalation primitives and deserve the same suspicion as iam:PassRole on AWS: roles/iam.serviceAccountUser (attach a service account to a resource, i.e. run code as it) and roles/iam.serviceAccountTokenCreator (mint tokens for it directly). Either one turns "can deploy" into "can act as anything that service account can act as".

Think of access as three gates in series, and a request must pass all three.

Allow policy — "is this principal granted the permission?" The gate that opens.
Deny policy — "is this principal explicitly refused it?" A veto that beats any allow, anywhere.
Principal access boundary (PAB) — "is this principal even eligible to touch resources in this part of the estate?" A containment fence drawn around the principal, independent of what it has been granted.

The PAB is the interesting one and the newest. It grants nothing. It answers a different question from "what may you do?" — namely "where are you allowed to be at all?". If your deployment service account is compromised, allow policies still describe what it can do; a PAB is what stops it from roaming across every folder in the organization while doing it.

Click each gate.

• It is fail-closed. If IAM cannot evaluate a PAB policy, access is denied. Google notes this commonly happens when newly created principals are still propagating — a security-positive default that makes identity lifecycle timing matter during rollouts and, awkwardly, during incident response.
• Multiple PABs can widen eligibility, not narrow it. This is the counter-intuitive one. A principal set may have up to 10 PAB policies bound to it, and binding a second one does not intersect with the first. Assuming "one more boundary means less access" is the classic PAB mistake.
• Enforcement versions matter. Each PAB declares which version of the permission set it enforces. Google warns against blindly using latest, since future changes could unexpectedly alter what is constrained.
• It is not a substitute for least privilege. PAB contains access; it does not design it. A wildcard allow policy inside a PAB is still a wildcard.
• Structurally: PAB policies are always children of the organization, and are available in the IAM v3 API. Bindings attach to a principal set — all identities in a project, folder or workload identity pool — rather than to individuals, which is what makes them practical at scale.

The mental model that makes all three clouds line up: PAB is to GCP what a permissions boundary is to AWS, arriving roughly seven years later and operating on principal sets rather than single principals. Azure still has no real equivalent.

Google Cloud, IAM policy types — cloud.google.com Troubleshoot policies — docs.cloud.google.com.

A GCP service account is the strangest object in cloud identity, because it is simultaneously two things: it is a principal that can be granted roles, and it is a resource that other principals can be granted roles on.

That duality is the whole story. Granting someone a role on a service account is granting them the ability to become it — which means a service account's own permissions are only half of its risk. The other half is who is allowed to wear it.

Google has named three separate features with nearly identical words. Getting these straight saves real time:

For GKE specifically there are now two configuration styles, and the newer one is simpler. Direct principal identifiers grant IAM roles straight to the Kubernetes ServiceAccount using a special principal syntax — no GCP service account in the middle at all. Service account impersonation is the older path: bind roles/iam.workloadIdentityUser with the member serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]. Start with the direct style; fall back to impersonation only when a service has limitations with federated tokens.

Two operational notes for your cluster work: it is always enabled on Autopilot, and on Standard the node pool needs --workload-metadata=GKE_METADATA, which blocks the raw 169.254.169.254 endpoint and routes through the GKE metadata server instead. Enabling it on an existing node pool requires recreating the nodes, so plan a maintenance window. If you know AWS IRSA, this is the same idea with different nouns.

Google Cloud, Authenticate to Google Cloud APIs from GKE workloads — docs.cloud.google.com.

The distinction mirrors Azure's RBAC-versus-Policy split exactly, and it is worth holding in the same shape:

The constraints that matter most for a GenAI estate, and which you should consider setting on day one:

• iam.disableServiceAccountKeyCreation — forbids downloadable key files outright. The single highest-value constraint on this list.
• iam.allowedPolicyMemberDomains — domain-restricted sharing; prevents anyone granting access to an identity outside your organization. This is Google's answer to the AWS data-perimeter problem.
• storage.publicAccessPrevention — blocks allUsers and allAuthenticatedUsers on buckets, closing the classic public-bucket failure at the platform level rather than by vigilance.
• compute.vmExternalIpAccess — restricts public IPs on VMs. Not identity, but it caps the exposure of anything that does hold an identity.
• Custom constraints let you write your own rules against resource fields in CEL, which is the closest GCP gets to Azure Policy's expressiveness — though still without a remediation effect.

When you ran your Vertex AI deployment script, you chose a machine type, a GPU, a scaling range and a spot policy. You almost certainly did not choose an identity — and one was chosen for you.

Google provisions service agents: Google-managed service accounts, created automatically per project per product, that platform services act as on your behalf. The Vertex family's is often written as a P4SA — Per-Project, Per-Product Service Agent. It exists so that Vertex can read your training data, write your model artefacts and pull your containers without you wiring anything up.

That convenience is the problem. A service agent's permissions are sized for everything the product might need to do in any project, not for what your specific job does. Google's own documentation says it plainly: the default Vertex AI service agent has access to BigQuery and Cloud Storage, and if you want fewer permissions than that, you must supply your own service account.

The fix is bring your own service account: create a narrow user-managed service account and tell Vertex to run as it. Configurable for custom training jobs, hyperparameter tuning jobs, training pipelines, deployed models serving online predictions, and Ray on Vertex AI clusters.

# the identity your endpoint actually runs as — set it explicitly
gcloud iam service-accounts create vllm-serving --project=ml-serving

# exactly one grant: read one prefix of one bucket
gcloud storage buckets add-iam-policy-binding gs://model-weights \
  --member="serviceAccount:vllm-serving@ml-serving.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/model-weights/objects/gemma-2b/"),title=gemma-only'

# then pass --service-account=vllm-serving@... when deploying the model

Four caveats that are easy to trip over, all from Google's documentation:

• The default prediction-container service account has permission to read model artefacts at the URI in AIP_STORAGE_URI — and Google explicitly says not to rely on it having any other permissions, because you cannot customise them.
• You cannot use a custom service account to pull images from Artifact Registry. The default service agent is still used for image pulls. So BYOSA narrows the runtime identity, not every identity in the flow.
• For batch inference, the service agent is still used to reach BigQuery and Cloud Storage even when a custom service account is configured.
• There is a cap of 20 custom service accounts per project, per region, per service.

Google Cloud, Use a custom service account — docs.cloud.google.com.

Multiple independent research teams have published attack paths that turn over-permissioned Vertex service agents into project-wide access. The pattern is consistent enough to be worth treating as a class rather than a series of bugs:

• ModeLeak (Unit 42, November 2024). Two escalation paths in earlier Vertex components. One via a custom-code service agent that could list all service accounts and read and write all storage buckets; one via model exfiltration, where deploying a malicious model gave access to all fine-tuned models in the project's Cloud Storage. The full chain ran from a poisoned public model upload to exfiltration of proprietary fine-tuned adapter weights — LLM intellectual-property theft without ever touching the training infrastructure.
• XM Cyber's disclosures (January 2026) on Vertex AI Agent Engine and Ray on Vertex AI: users holding read-only Viewer permissions could extract service agent credentials from the instance metadata service and obtain project-wide access to Cloud Storage, BigQuery, Pub/Sub and Artifact Registry. Google classified both as "working as intended", with no remediation planned at the time.
• Unit 42's "Double Agents" (disclosed 31 March 2026): the P4SA provisioned by default for Vertex AI Agent Engine deployments carries permissions letting a compromised or misconfigured agent read every Cloud Storage bucket in the project, reach private container registries, and pivot laterally. The researchers note the chain requires no novel exploit — it consists entirely of querying the standard metadata service for credentials that were already there.

That last sentence is the one to carry. This is the Session 1 warning about metadata endpoints arriving in your exact domain: workload identity removes credential theft-at-rest and does nothing about credential abuse-at-runtime. Any code executing in the agent runtime — a compromised dependency, an injected prompt that reaches a tool, your own bug — can ask the metadata server for the token, and the platform will hand it over, because from the platform's point of view the request is entirely legitimate.

Cloud Security Alliance research notes on Vertex AI service agent privilege escalation and AI agents as cloud escalation vectors.