Cloud Identity and Permissions: Where the New Access Cards Live

Core premise: in a traditional data centre, an attacker wants "a username and password". In the cloud, they want an identity that is trusted — and that identity may not be human; it may be a program. Angle: concepts and tightening guidance. No operational detail.

The shape of credentials changed; the risk did not

Recall the traditional environment: logging in required a username and password; servers calling each other often used a credential pair written into a config file.

The cloud changed that. Now:

• an application calls a database using a service principal (a program identity);
• a program accessing a storage bucket receives a temporary credential (with an expiry);
• a deployment pipeline needs a secret, possibly stored in a CI/CD environment variable.

The shape changed, but the attacker's objective did not: obtain a trusted identity.

Four concepts worth separating

Concept one: service principal / service account

Plainly: an identity that is "not a person", representing an application or automation.

Why it matters: people leave, change passwords, and attract audit attention; service principals are often long-lived, permanently valid, and rarely reviewed. If a credential leaks, it may go unnoticed for years.

Concept two: roles and permission bindings

Plainly: cloud platforms do not grant permissions directly to an identity. They define a role (what may be done), then bind that role to identities.

Why it matters: the design exists for flexibility and manageability, but the practical failure is over-broad binding — more permission than needed, rarely narrowed.

Concept three: temporary credentials

Plainly: a credential with an expiry. It stops working when the time is up.

Why it matters: this is the cloud's biggest security dividend over traditional environments. A long-lived key that leaks is a permanent gap; temporary credentials compress the exposure window to hours.

A useful test: if your environment contains lots of long-lived keys, the answer is simple — everything that can move to temporary credentials should move.

Concept four: CI/CD secrets

Plainly: credentials the automation pipeline needs.

Why it matters: these secrets usually carry broad permissions (deploy, change configuration, read other secrets) and live in repositories or build systems — so a leak has wide blast radius.

Five most common blind spots

Blind spot one: long-lived keys scattered everywhere

The common state: multiple systems each hold a long-lived key, and nobody knows how many exist, when they were created, or who uses them.

Tightening: start with an inventory — "how many long-lived credentials do we have, and where?" Many enterprises are startled by their first count.

Blind spot two: over-broad permissions ("it is all internal anyway")

When binding roles, people often grant a wide scope to avoid mistakes.

Tightening: start from least privilege and add as needed — not the reverse.

Blind spot three: accidentally public buckets and services

The classic cloud incident: a storage bucket is misconfigured and readable by anyone.

Tightening: automate the check for public access settings rather than relying on memory.

Blind spot four: logs enabled but unread

Enabling audit logs is good; if nobody reviews them and no anomaly alerting exists, they only consume storage.

Tightening: name who reviews, how often, and what triggers an alert.

Blind spot five: offboarding and vendor processes miss the cloud

HR changes revoke internal system access, but cloud service principals and vendor role bindings are frequently overlooked.

Tightening: put cloud permissions on the same "staff/vendor change checklist".

A practical tightening order

Ranked by return, proceed in this order:

1. Inventory: list all long-lived credentials, all service principals, all publicly exposed resources;
2. Go temporary: replace every long-lived key that can become a temporary credential;
3. Narrow: reduce each permission binding to what is actually needed;
4. Watch: name an owner and define alert conditions;
5. Process: add cloud permissions to staff and vendor change checklists;
6. Review: quarterly check of "who has what, and is it still needed".

Why this connects to AI agents

Connect the pieces: the resource attackers — human or agent — chase hardest in the chain is credentials. In a cloud environment there are far more credentials than in a traditional one: every service principal, every pipeline, every automation is a potential credential.

That means credential isolation is harder in the cloud — and more valuable.

Three one-liners

1. Cloud identities are not only people. Service principals are often more dangerous than human accounts because they are reviewed less.
2. Temporary credentials are the biggest dividend. Move whatever can move — it turns a permanent gap into a few-hour gap.
3. Narrowing happens one step at a time. Nobody gets it right in one pass; every pass should move the right direction.

Next steps

• For supply-chain risk (cloud dependency is one link), read supply chain and third-party risk
• For credentials in traditional environments, read credentials and AD concepts
• For an overall defensive review, read defense lessons from a red-team postmortem