[Security Architecture] Authorization and IAM

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 authentication lets you through the keyhole, the system stays permanently exposed unless authorization narrows how far you can go in. The question this article asks is “what do we allow whom to do.” It covers the three models RBAC / ABAC / ReBAC, the least-privilege principle, IAM operations, and why machine permissions have to be stricter than human ones 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.

Why authorization and IAM matter

Authentication can confirm who somebody is, and sloppy permission design still leaves everyone effectively at admin. Permissions nobody needs enlarge the damage from insider misconduct and mis-operations, and cases where a leaver keeps their access are common. SOX, data-protection law, HIPAA and many other regimes demand that “who can access what” be managed and audited, and an organisation without IAM in place fails the audit. On top of that, the cloud era brings hundreds of API types in AWS alone, and manual permission management breaks down.

The three authorization models — RBAC / ABAC / ReBAC

RBAC — enough for 90% of systems

Permissions are bundled into roles and roles are assigned to users. Roles such as “sales,” “accounting,” “admin” keep management simple and auditing easy, and more than 90% of systems are RBAC-based. Its weaknesses are that it handles exceptions badly, and that passing 100 roles is a sign of impending breakdown, which is the signal to consider moving to ABAC.

ABAC — fine-grained conditional control

Permissions are decided dynamically from attributes of the user, the resource and the environment. Multi-dimensional control such as “a rep in sales at the Tokyo office sees only their own department’s customer records” becomes possible, which avoids role explosion. The Condition clause in AWS IAM policies is effectively ABAC, and in open source OPA (Open Policy Agent) and Cedar (from AWS) are the standard choices. The price is that design and auditing get harder.

ReBAC — the Google Docs sharing model

Permissions are decided by the relationships between resources; Google’s Zanzibar is the well-known example. Graph-shaped permission management — “members of this document’s owner group can edit it,” “share a folder and the files beneath it are shared automatically” — comes naturally, which pays off in SaaS and social products. SpiceDB and OpenFGA are the standard implementations. If sharing is the main event, ReBAC; for ordinary business systems, RBAC is enough.

The least-privilege principle and IAM operations

One of the most important principles in security is to grant only the minimum permissions the work requires. “Admin for now” is the worst anti-pattern. Starting from ReadOnly plus explicit Actions and widening when a need appears is the only safe design: widening later is easy, narrowing is next to impossible.

The 2019 Capital One breach began with a WAF misconfiguration (SSRF), and the lethal factor was that the EC2 instance’s IAM role held excessive permissions — roughly 106 million customer records were taken out of S3. Had least privilege been maintained, breaching the WAF would not have reached S3.

Operationally the basics are: same-day removal of permissions for leavers and transfers, a quarterly permission review, a ban on day-to-day use of root and admin accounts (MFA required, separate IAM users), and separate roles for production and development.

Machine-to-machine authentication and AI agents

Authentication and authorization between systems rather than between people is an important part of IAM too. Service Accounts for services inside a cloud, Workload Identity from a Kubernetes pod to a cloud API, mTLS between microservices, and OAuth Client Credentials for external integration are the standard choices — and in all of them the modern standard is to avoid permanent API keys as far as possible and issue short-lived tokens.

Where permissions are delegated (AWS Role Assumption, OAuth On-Behalf-Of and the like), audit logs must make “who did what under whose permission” traceable. A wrong implementation invites the Confused Deputy — an attack that tricks a privileged intermediary into acting on the attacker’s behalf.

How to choose — a phased roadmap

Going “straight to ABAC” stalls operations, so IAM is promoted in stages as scale and complexity grow.

In regulated industries the audit requirements are layered on top of the model choice: segregation of duties and approval flows in finance, access logs and per-patient control in healthcare, multi-stage approval in government.

Three scenarios

If you are building solo or at a startup

Plain RBAC with three to five roles (admin, editor, viewer) is enough. Ride the standard role features of Clerk or Supabase Auth and keep the authorization check in one place in middleware. Building ABAC or ReBAC at this stage is straightforwardly over-engineering.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

Start from RBAC plus a department attribute, and consider ReBAC (OpenFGA or SpiceDB) at the point where sharing across tenants appears — “share this document with this user.” B2B contracts will always bring requests to customise roles, so holding role definitions as configuration data rather than in code saves trouble later.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large or regulated enterprise

The full kit: ABAC (OPA or Cedar) with segregation of duties, approval flows and audit logs. Finance adds segregation of duties, healthcare per-patient access control, government multi-stage approval — the regulatory requirements stack on top of the model choice. Unless staff movements and permission changes are automated through the IdP, every review turns into an enormous manual exercise.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — Agent permissions must be stricter than human ones

IAM design for AI agents has become a new essential

Configurations where AI agents generate code, deploy and access data in production are increasing. Because AI carries out large numbers of operations far faster than a person, its permissions have to be designed more strictly than a human’s. Concretely: a separate IAM role per agent (no reusing a shared role), an explicit limit on operation scope, token lifetimes within an hour, and audit logging of every operation with automated anomaly detection.

IAM policies written by AI tend to be over-permissive

You can have an AI write IAM policy JSON, and it will favour “making it work” and produce over-permissive entries such as "Resource": "*" or "Action": "s3:*". A CI check such as IAM Access Analyzer has to be built in so that excessive permissions are detected automatically. If policies are already codified in OPA or Cedar and kept in Git, that check drops straight into pull-request review.

Pitfalls and forbidden moves

Here are the six most dangerous instances of the structure excessive permissions → maximum damage when breached.

Author’s note — how “excessive permissions” sank companies in one shot

The best known is the 2019 Capital One incident, where “one lax line in an IAM role” turned into a fine on the order of $80 million (details in the appendix on major incidents). In another case surfacing in 2019 at a large US bank, a departed engineer’s AWS account had gone months without being deleted and was used as a stepping stone for insider misconduct. A single missing line for IAM on the offboarding checklist — a mundane mistake — led to damage in the tens of millions.

Neither was a flashy zero-day. The root cause in both was “neglecting least privilege and reviews.” With IAM, unglamorous operations are the strongest defence: least privilege, regular reviews, and policies kept as code.

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

For each of the following, try to articulate your project’s answer in one or two sentences. Start work with these left vague and you will always be asked later, “why did we decide it that way?”

• Authorization model (RBAC / ABAC / ReBAC)
• Role design (an inventory of the business roles)
• Policy management (codified in OPA / Cedar and kept in Git)
• Least-privilege operations (review frequency, approval flow)
• Machine-to-machine authentication (Service Accounts, mTLS, short-lived tokens)
• The AI agent’s permission boundary (scope, expiry, audit logs)

Related Articles

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.