[Security Architecture] Authorization and IAM - Sticking to Least Privilege

About this article

As the third installment of the “Security Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains authorization and IAM.

Even after auth lets you through the keyhole, without authorization narrowing how far you can go in, the system is permanently exposed (the Capital One incident’s 100M-row leak is the typical case). This article covers the 3 models RBAC/ABAC/ReBAC, the least-privilege principle, IAM operation, Service Accounts, and why machine permissions should be stricter than humans in the AI era.

What is authorization and IAM in the first place

Authorization and IAM are, roughly speaking, “the mechanism for finely controlling what an identity-verified party is allowed to do.”

Imagine a hotel card key. Everyone passes check-in (authentication), but the rooms each card key opens differ by person. Regular guests can only enter their own room, housekeeping staff can access all floors, and the general manager can open every room plus the vault. Designing “who is allowed what” is authorization, and the system for centrally managing large numbers of users and permissions is IAM (Identity and Access Management).

This article’s coverage

Article	Coverage
This article (authorization and IAM)	RBAC / ABAC / ReBAC / least privilege / IAM operation / Service Account
50/01 Authentication design	Auth strength / MFA / Passkey / IDaaS / SSO
20/07 Authentication and sessions	Session tech / JWT / OAuth implementation
30/07 Auth	Browser-side authorization UI / XSS / CSRF

The question of this article is “what do we allow whom to do.” Not identity verification - the design and operation of permissions.

The more people you hand keys to, the more dangerous the house

Even with authentication confirming “who,” sloppy permission design puts everyone at admin. Authorization grants the bare minimum based on the least-privilege principle.

“Admin permission for everyone” is the most common breeding ground for incidents. Stick to least privilege.

Why it’s needed

1. Limit the damage of insider misconduct/accidents

Granting unnecessary permissions causes major damage from insider misconduct or accidental operations. Cases where retirees retain access also happen often.

2. Regulation/audit response

SOX (US Sarbanes-Oxley Act), Personal Information Protection Act, HIPAA (US health-info protection law) - many regulations demand management and audits of who can access what. Without IAM in place, audits fail.

3. Cloud era explodes permissions

AWS alone has hundreds of API types, and as microservices and SaaS grow, permission management gets complex. Manual management breaks down, requiring systematic IAM design.

Authentication vs authorization

Two often-confused concepts, but their roles differ clearly. Authentication confirms “who,” authorization decides “what they can do.” Safe access control only happens with both in place.

	Authentication (AuthN)	Authorization (AuthZ)
Purpose	Identity verification	Permission decision
Question	”Who are you?"	"Do you have permission?”
Timing	At login	At each operation
Example	Password, MFA	File read, admin screen

Authentication happens once, authorization every time. How lightly and accurately authorization logic is designed determines system scalability and security.

flowchart LR
    subgraph RBAC_BLOCK["RBAC (role-based)"]
        U1[User] --> R1[Role]
        R1 --> P1[Permission]
    end
    subgraph ABAC_BLOCK["ABAC (attribute-based)"]
        U2[User attributes] --> POL[Policy]
        RES[Resource attributes] --> POL
        ENV[Environment attributes<br/>time/location] --> POL
        POL --> P2[Permission decision]
    end
    subgraph REBAC_BLOCK["ReBAC (relation-based)"]
        U3[User] -.|owner of| DOC1[Doc]
        U3 -.|member of| TEAM[Team]
        TEAM -.|access to| DOC2[Doc]
    end
    classDef rbac fill:#dbeafe,stroke:#2563eb;
    classDef abac fill:#fef3c7,stroke:#d97706;
    classDef rebac fill:#fae8ff,stroke:#a21caf;
    class RBAC_BLOCK,U1,R1,P1 rbac;
    class ABAC_BLOCK,U2,RES,ENV,POL,P2 abac;
    class REBAC_BLOCK,U3,DOC1,DOC2,TEAM rebac;

RBAC (role-based authorization)

RBAC bundles permissions into roles and assigns roles to users. Define needed permissions for roles like “sales,” “accounting,” “admin,” and just assigning roles to users manages permissions. Management is simple, and 90%+ of systems are RBAC-based.

Pros	Cons
Simple management	Bad at exceptional cases
Audit-friendly	Role explosion (hundreds of roles)
Bulk changes are easy	Coarse granularity

When role count exceeds 100, it’s a sign of breakdown - and a sign to consider migrating to ABAC.

ABAC (attribute-based authorization)

ABAC uses user, resource, and environment attributes to dynamically decide permissions. Fine-grained control like “sales reps in the Tokyo office can only see their own department’s customer info” is possible, expressing complex rules RBAC can’t.

Pros	Cons
Flexible and fine-grained	Hard to design
Avoids role explosion	Complex to audit
Time/location control	High implementation cost

AWS IAM policies are effectively ABAC, with the Condition clause enabling attribute-based control. Open Policy Agent (OPA) and Cedar (by AWS) are notable OSS implementations.

ReBAC (relation-based authorization)

ReBAC decides permissions using relationships between resources, with Google’s Zanzibar being famous. Graph-structured permission management like “members of this document’s owner group can edit” is possible, showing power in SaaS and social services.

Suited situation	Example
Hierarchical structure	Org-hierarchy permission inheritance
Ownership	Document/folder ownership
Membership	Group/team unit
Shared links	External publishing, invites

OSS implementations: SpiceDB, OpenFGA (Auth0), Permify - these are modern ReBAC implementations. If you need Google Docs-like flexible sharing, ReBAC is worth considering.

If you have Google Docs-like sharing features, ReBAC. Normal business systems are fine with RBAC.

The least-privilege principle

One of the most important principles in security - grant only the minimum permissions needed for work. “Admin permission for now” is the worst antipattern, and to minimize damage on breach, permissions are always narrowed.

Don’t do this	Right design
Everyone admin	Role-based per role
Permanent API keys	Short-lived tokens, rotation
All-resource access	Narrow per resource
Common permissions for prod and dev	Separate roles per environment

Periodic permission reviews also matter - retirees’ and transferees’ permissions removed instantly, unused permissions periodically narrowed - the operational basics. The July 2019 Capital One information leak incident exploited overly-set IAM roles and a WAF misconfiguration, exfiltrating about 106M customer records from S3. If least privilege had been maintained, even with the WAF breached, S3 wouldn’t have been reached.

Main IAM concepts

IAM is designed by combining several concepts. Cloud (AWS/GCP/Azure) IAM has slightly different terminology, but the structure is roughly the same.

Concept	Meaning
Identity	Subject like person, service, device
Principal	Entity granted permissions
Role	Bundle of permissions
Policy	Concrete allow/deny rules
Resource	Protected target (data, API, etc.)
Action	Operation (read, write, delete)
Condition	Conditions (time, location, MFA presence)

Cloud IAM comparison

The 3 cloud IAMs differ slightly in design philosophy, each with its own quirks. When using multiple clouds, both must be correctly understood.

Feature	AWS IAM	GCP IAM	Azure AD
Basic model	Policy-centric, fine	Role-centric, simple	RBAC-centric, hierarchical
Granularity	Extremely fine	Mid	Fine
Learning cost	High	Low	Mid
Best practice	Least privilege, role separation	Built-in roles preferred	Group-centric

AWS IAM is fine-grained but hard, so many companies entrust policy design to specialists.

Service accounts and machine-to-machine auth

Auth and authorization between systems, not between people, is also a critical IAM area. Inter-microservice communication, batch jobs, AI agents - non-human accesses are exploding.

Auth method	Use case
Service Account	Inter-service in cloud
Workload Identity	K8s (Kubernetes) Pod → cloud API
mTLS (mutual TLS)	Inter-microservice
OAuth Client Credentials	External-system integration
SPIFFE / SPIRE	Universal ID foundation (OSS standard)

Avoid permanent API keys whenever possible - the modern standard is designs that issue short-lived tokens.

Permission delegation and proxy access

Permission delegation patterns like “B works with A’s permissions” or “service A calls with service B’s permissions” are also design issues. Misimplementation invites hijacking attacks (Confused Deputy, the trick of fooling a permission-holding intermediary into proxying the attacker’s operations).

Pattern	Method
Role Assumption (AWS)	Temporarily transform into another role via STS (Security Token Service)
Impersonation (GCP)	Service-account proxy execution
On-Behalf-Of (OAuth)	Proxy operation for an authorized user
Delegation	Explicit permission grant

For delegation, audit logs must let you trace “who did what under whose permission.”

Decision criteria

1. System scale

IAM complexity is decided by system scale. Adopting ABAC or ReBAC at small scale is excessive and operations can’t keep up.

Scale	Recommended
Small, few roles	RBAC (keep it simple)
Mid, with conditional branches	RBAC + attribute conditions
Large, complex permissions	ABAC (OPA, Cedar)
Heavy social/sharing	ReBAC (SpiceDB, OpenFGA)

2. Regulatory requirements

Industries needing audit response require mechanisms to record all permission grants, changes, and uses.

Industry	Required IAM requirements
Finance	Segregation of duties, approval flow, audit logs
Medical	Access logs, least privilege, per-patient control
Government	Multi-stage approval, physical isolation, clearance
General companies	Retiree processing, periodic review

How to choose by case

General business SaaS (department and role as primary axis)

RBAC + cloud-IAM built-in roles. Cut roles by department/job, centralize management with Okta/Entra ID. If complexity grows, augment with conditions.

Google Docs-style sharing model (owner, viewer)

ReBAC (SpiceDB / OpenFGA). Express ownership/sharing/hierarchy as a graph, naturally implementing behaviors like “user shares a folder, descendant files auto-share.”

Strict access control for finance/medical

ABAC (OPA / Cedar) + strong auditing. Multi-dimensional conditions like dept x data type x time of day x MFA presence. Bake approval flows and segregation of duties into IAM.

Inter-microservice / AI agents

Workload Identity + short-lived tokens + mTLS. Permanent API keys forbidden. Issue dedicated service accounts per agent, minimize scope.

Phased permission-design roadmap

IAM “all-at-once ABAC” freezes operations - phase up by scale and complexity.

Phase	People/scale	Recommended model	Implementation example	Role count target
1. Startup	~10	Plain RBAC	admin / editor / viewer	3-5
2. Growth	~30	RBAC + dept attributes	RBAC + Department condition	10-30
3. Mid-size SaaS	~300	ABAC (attribute-based)	Conditioned with OPA / Cedar	30-100
4. With sharing features	Any size	ReBAC (relation-based)	OpenFGA / SpiceDB	Graph relations
5. Large/regulated	3,000+	ABAC + segregation of duties	Approval flow + audit logs	Hundreds

“Role count over 100 is a sign of breakdown,” and a sign to consider ABAC migration. “Admin for now” is the worst antipattern that maximizes damage on breach. Start by narrowing to one role and broaden permissions as needs arise - the only safe design.

For permissions, start from ReadOnly + explicit Action. Broadening later is easy, narrowing is nearly impossible.

IAM-operation pitfalls and forbidden moves

Here are the typical accident patterns in IAM. All have the structure of excessive permissions → maximum damage on breach.

Forbidden move	Why it’s bad
Develop/operate with “admin for now”	The day to narrow never comes. The pattern of the Capital One 2019 incident (over-IAM-role leaking 106M records)
Embed permanent API keys in apps	Instant access on leak. Move to OIDC Federation + temporary auth + Service Accounts
Leave retirees’ access permissions for months	The 2019 US major bank insider-fraud case. Day-of-retirement deprovisioning automation is required
Don’t conduct role reviews	Permissions accumulate, all-admin. Quarterly review operations
Daily use of root/admin accounts	One ops mistake at maximum permissions wipes everything. Required MFA + separate IAM users
Treat service accounts as human users	MFA hard, opaque permission management. Separate Service-Account-only roles
Common permissions for prod/dev/staging	Dev mistakes propagate to prod. Per-environment role separation
Manage policies by hand in GUI	No change history, irreproducible. Code-ize with OPA / Cedar + Git
Grant AI agents admin permissions	High-speed mass operations cause severe damage. Per-agent dedicated minimum permissions
Store audit logs inside the production account	Logs erased on breach. Separate account + WORM
”Admin for now, narrow later” left as is	The day to narrow never comes; permissions accumulate, all-admin
”Authorization can be left for later” deferred	The hardest feature to bolt on later; build into initial design

The Capital One 2019 incident is the typical example where one line of laxness in an IAM role turns into billions in damage (details in this article’s industry-cases section and the appendix “Critical Incident Cases”).

IAM’s strongest defense is mundane operations. Least privilege + periodic review + policy code-ization.

AI decision axes

AI-era favorable	AI-era unfavorable
Short-lived tokens, scope-limited	Permanent API keys, all permissions
Code-ize policies with OPA/Cedar	Manual management in setting screens
Different roles per agent	Common role for all agents
Operation logs and auditing complete	No logs, history untraceable

1. Stick to least privilege — ban admin defaults, grant only minimums, periodic reviews
2. Choose model by scale — small RBAC, mid-large ABAC, sharing-central ReBAC
3. Manage policies as code — use OPA / Cedar + Git; manual GUI management is a person-locking trap
4. Stricter agent permissions than humans — short-lived tokens, scope-limited, full operation logs

Author’s note - cases where “excessive permissions” sank companies in one shot

Stories of IAM-design neglect sinking a company in one shot are perennial in security. The most famous is the 2019 Capital One information-leak incident, where a former AWS engineer’s “WAF-misconfig-routed SSRF attack” was the entry, and the fact that the EC2 instance’s IAM role had excessive permissions was the lethal blow - about 106M customer records were exfiltrated from S3. Maintaining least privilege would have meant even with the WAF breached, S3 wouldn’t be reached - “one line of laxness in an IAM role” turned into an $80M-class fine, told as a case.

Another - in 2019, a US major bank uncovered a case where “a retired ex-engineer’s AWS account remained for months without deletion,” used as a stepping-stone for insider-fraud customer-data exfiltration. Just one line missing for AWS IAM on the retirement-processing checklist - a mundane mistake leading to tens of millions in damage - the typical example.

I also once accidentally extended a strong permission granted for testing to a production user, and didn’t notice until pointed out in audit. None of these were flashy zero-day attacks - the root cause was “neglect of least privilege and review,” and they slap home the lesson that mundane operations are the strongest defense.

IAM accidents happen by one line of laxness. Reviews and policy code-ization are the strongest defense.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Authorization model (RBAC / ABAC / ReBAC)
• Role design (inventory of business roles)
• Policy management method (code-ization, GitOps (operation that auto-reflects from Git-managed files))
• Least-privilege operation (review frequency, approval flow)
• Inter-machine auth (Service Account, mTLS)
• Audit logs (who did what when)
• AI-agent permission boundary (scope, expiry)

Summary

This article covered authorization and IAM, including the 3 models RBAC/ABAC/ReBAC, least privilege, IAM operation, Service Accounts, and why machine permissions should be stricter than humans in the AI era.

Stick to least privilege, choose model by scale, manage policies as code, and make agent permissions stricter than humans. That is the practical answer for authorization and IAM in 2026.

Next time we’ll cover encryption (TLS, AES, KMS, key management).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.