DEV Community: viola

How is your IAM? | Google Cloud edition

viola — Sat, 25 Apr 2026 17:37:31 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

What is this piece about: IAM is evolving from access control into a trust grid for humans, workloads, service accounts, and agents, and Google Cloud NEXT '26 makes this very clear, but how is your IAM?

I have been an avid user of Google Cloud and the ecosystem around it for years. My own journey started with Firebase, because it gives developers a ridiculous amount of capability before they even have to think about infrastructure properly. And this is both the beauty and the trap of cloud platforms.

Cloud platforms allow you to build and ship quickly, connecting your products, APIs, databases, serverless functions, CI/CD pipelines, logs....

...analytics, security tools, and now agents faster than ever before.

Then someone in the business asks:

Who exactly can access what?

And that is usually the point where the room falls silent, because everyone knows the answer is more complicated than it should be.

For the past few years, I have worked around cloud architecture, security, and cost optimisation. I have seen companies spend way too much money on cloud resources, but the scarier issue is usually not cost. The bill may hurt, but unclear access is what keeps me awake.

Somewhere along the way, it became almost instinctive: every cloud security conversation began with the same question.

How is your IAM?

And often, the answer would move straight into comfortable territory. RBAC, improved login journeys, cleaner onboarding, smoother user flows. All important, but not enough. What was usually missing was the harder conversation about blind spots, the forgotten edges where unauthorised access is most likely to creep in.

That is what the picture below captures so well. Experienced engineers mapping the paths they expect users and systems to take, while the dangerous paths sit quietly outside the frame.

I mean, can you explain the trust graph inside your cloud?

Because in Google Cloud, IAM is not one lock on one door. It is a policy system spread across organizations, folders, projects, workloads, service accounts, APIs, logs, secrets, pipelines, and now agents. And after Google Cloud NEXT '26, that question matters even more.

Google Cloud NEXT '26 felt less like a parade of AI features and more like the outline of a new operating reality. Through Gemini Enterprise Agent Platform, Agent Identity, Agent Gateway, Agent Observability, Agentic Defense, and Agentic Data Cloud, Google was naming the shape of the next cloud era. One where agents are no longer passive assistants, but actors inside the control plane itself.

Agents stop being "just chatbots" the moment they can call tools, query data, inspect incidents, trigger workflows, and act on behalf of users.

At that point, they cross a boundary.

They become participants in the identity system itself.

And once that happens, IAM is no longer managing only people and workloads. It is managing delegated intent.

IAM is not a login screen

A lot of teams still speak about IAM as though it begins and ends with the login journey. If the user can sign in, if the role-based access control looks reasonable on paper, if MFA is enabled, then the system is treated as though it has passed some invisible security threshold.

But IAM is not the login screen. It is not the modal where a user enters an email address, and it is not the friendly redirect that takes them back into the application.

Authentication asks who someone is. Authorization asks what they are allowed to do. Cloud IAM has to ask a larger and more uncomfortable question.

Which principal can perform which action on which resource, under which policy, and with what blast radius if that permission is misused?

That question sounds clean in theory, but it becomes complicated as soon as you look at the number of identities that exist inside a real cloud environment. A principal can be a human user, a group, a service account, a workload identity, an external identity from another provider, or an automated system moving quietly in the background.

And now, increasingly, a principal can also be an agent.

That is where the conversation changes. Once agents can call tools, query data, inspect incidents, trigger workflows, or act on behalf of a user, they stop being a decorative AI layer around the edge of the system. They become participants in the identity model itself.

That is why IAM cannot be treated as a narrow authentication concern. IAM is the control plane for trust.

The basic model is simple. The real model is not.

At the conceptual level, Google Cloud IAM looks almost elegant. A principal receives a role on a resource. The role contains permissions. The resource belongs somewhere in the hierarchy. The policy determines whether the action is allowed.

That is the version we can draw neatly on a whiteboard.

Production rarely stays that neat.

A user belongs to a group. That group inherits access from a folder. A project contains a service account. A workload can impersonate that service account. A CI/CD pipeline can deploy the workload. The workload can read secrets. Those secrets can unlock third-party systems. Logs can expose sensitive data. An agent can call a tool. That tool can reach an internal API. That API can touch customer data.

No single step in that chain may look dramatic on its own. That is the dangerous part.

Cloud risk often hides in the relationship between permissions, not just in the permission itself. The obvious question is whether an identity has a role. The better question is what that role allows the identity to reach, directly or indirectly.

This is why I no longer think about IAM as a gate.

I think about it as a grid.

A grid of trust transitions, where every identity, policy, resource, workload, tool, and agent creates another possible path through the system.

And sometimes the risk is not one obviously dangerous role.

Sometimes the risk is the chain.

The hierarchy is clean. Effective access is not.

Google Cloud gives us a resource hierarchy that looks clean from a governance perspective. Organizations, folders, projects, and resources give teams a way to structure ownership, policy, and control.

That hierarchy is useful. It gives large environments shape. It allows policies to be managed at different levels. It gives platform teams a way to apply governance without configuring every single resource manually.

But the same hierarchy also creates inherited access, and inherited access is where confidence can become misleading.

A role granted too high in the structure can quietly become broader than anyone intended. A folder-level permission can reach more projects than expected. A viewer role can expose more sensitive operational context than the name suggests. A service account that looks harmless in isolation can become highly privileged when combined with impersonation rights, deployment rights, or access to secrets.

This is where teams often get caught out.

Someone says that access was only granted at the folder level, but the more important question is what lived under that folder.

Someone says that a user only had Viewer, but the better question is what that user could view through logs, metadata, dashboards, configuration, or linked systems.

Someone says that it was just a service account, but the actual question is who could impersonate it, what it could access, and what it could trigger.

This is why least privilege is not just a security slogan.

In Google Cloud, least privilege is a graph reduction problem.

You are not only reducing roles. You are reducing reachability. You are reducing the number of paths an identity can use to create production impact. You are reducing the blast radius before there is a blast.

Positive paths are not enough

Most engineering teams are very good at explaining the positive path.

A user signs in. An admin grants a role. A service calls an API. A pipeline deploys. A dashboard loads. The demo works. The user journey looks smooth. The architecture diagram makes sense. Everyone moves on.

But attackers do not follow the positive path. Misconfigurations do not stay neatly inside the intended path. Broken integrations do not respect the diagram. Agents, especially once they are connected to tools and workflows, will not always remain inside the path we imagined for them.

The more useful question is not whether the right identity can do the right thing.

The more useful question is whether the wrong identity can reach the same outcome through a side route.

That is where cloud security actually lives.

Can a developer impersonate a privileged service account? Can a CI job deploy code that runs with broader permissions than the pipeline itself? Can a support role read logs containing customer data? Can read-only access still expose secrets through metadata or operational traces? Can an agent call a tool that performs a privileged action on its behalf? Can an abandoned service account still reach production? Can a temporary exception slowly become permanent infrastructure?

These are not edge cases. They are the places where real incidents are born.

This is the difference between IAM existing and IAM working.

Service accounts were the first warning

Before agents entered the conversation, service accounts had already shown us that IAM was never only about humans.

A service account is a non-human identity that can act inside the system without anyone sitting there and clicking a button. That can sound like plumbing until you realise how much of a modern production environment depends on it.

Service accounts run workloads. They access APIs. They deploy systems. They read data. They integrate platforms. They sit inside CI/CD pipelines, automation scripts, configuration files, and sometimes places they should never have reached in the first place.

The industry has already learned this lesson the hard way. Leaked service account keys, default accounts with excessive access, broad Editor roles, forgotten CI credentials, and unreviewed impersonation paths have all shown the same pattern.

The problem is rarely that nobody configured IAM at all. The problem is that the identity model grew faster than the governance around it.

Google Cloud’s own service account best practices point teams toward avoiding unnecessary keys, reducing excessive privilege, using temporary privilege elevation, reviewing unused permissions, and paying attention to lateral movement risk.

That list tells us where real IAM risk lives. Standing privilege. Overbroad roles. Long-lived credentials. Default accounts. Unused permissions. Lateral movement.

Now apply that same logic to agents.

An agent is not just a piece of software. In practical terms, it is a workload with reasoning, memory, delegated intent, and tools.

So the uncomfortable question becomes obvious.

Are we about to repeat every service account mistake, but faster?

Workload Identity Federation was the bridge

One of the better evolutions in cloud IAM has been the move away from long-lived static keys.

Static keys are dangerous because once they leak, they become portable access. They can sit in CI systems, laptops, scripts, Slack messages, old repositories, Docker images, backup folders, and forgotten configuration files for far longer than anyone wants to admit.

Workload Identity Federation moved the model in a better direction by allowing external workloads to use existing identity providers and obtain short-lived access without relying on long-lived service account keys.

That principle matters because it reveals the direction cloud IAM has been moving in for years.

Trust should be explicit. Credentials should be short-lived. Access should be scoped. Identity should be verifiable. Authority should be revocable.

Agents need the same discipline.

They should not be random API keys with a personality. They need proper identity. They need scoped permissions. They need tool boundaries. They need audit trails. They need revocation paths. They need to prove who or what they are before they act.

This is where Google Cloud NEXT ’26 becomes interesting.

Because the agentic cloud is not just about making agents more capable.

It is about making agents governable.

Agents are entering the IAM grid

Google Cloud’s Agent Identity work is an important signal because it treats agents as something that must be identifiable, governable, and accountable.

Agent Identity gives agents a secure per-agent identity in Agent Runtime and supports a least-privilege approach to access management. Google also describes lifecycle-tied identities, IAM allow and deny policy support, auditability, and credential protections such as certificate-bound tokens protected through Context-Aware Access.

That matters because once an agent can query data, call tools, inspect alerts, route requests, trigger workflows, or act on behalf of a user, it is no longer just an AI feature.

It is an actor inside the cloud trust model.

And actors need identity.

They need boundaries, logs, revocation, deny rules, runtime controls, and a clear relationship to the user, workload, or business process they are acting for.

Without that, we are not building an agentic cloud.

We are building shadow infrastructure with a nicer interface.

Agent Gateway and Model Armor are not AI safety fluff

This is the part I think developers should take seriously.

Agent Gateway is not just a routing layer. It is governance infrastructure for the way agents connect and interact across Google Cloud, external agents, AI applications, tools, and language models.

Model Armor is not just a generic safety wrapper either. It screens prompts and responses, and when it is integrated with Agent Gateway, those protections can sit directly in the communication pathways agents use.

That is important because IAM alone cannot understand every model interaction.

IAM can determine whether a principal is allowed to perform a particular action. It can enforce policy against identity, role, permission, and resource.

But agentic systems introduce other questions.

What is being sent to the model? What is being returned? Is the agent being manipulated? Is sensitive data crossing a boundary? Is a tool being invoked through an unsafe chain? Is the interaction consistent with the agent’s intended purpose, or has the agent drifted into behaviour nobody explicitly approved?

The enforcement model has to become layered.

IAM controls who or what can act. Agent Identity makes the agent visible as a first-class identity. Agent Gateway governs where agent traffic flows. Model Armor screens the model boundary. Deny policies and principal boundaries limit what should never be reachable. Audit logs make the activity explainable after the fact.

That is the deeper cloud security story.

Not simply adding AI to the stack.

But governing a new class of actor once it starts operating inside the cloud.

If agents are going to act inside production systems, they need to be governed like production identities.

Every agent should be less privileged than the human who created it

My strongest opinion on agentic IAM is simple.

Every agent should be less privileged than the human who created it.

That sounds obvious, but I think many teams will get this wrong.

They will connect agents to broad service accounts because the demo needs to work. They will let agents inherit human access because it feels convenient. They will give agents tools without mapping the downstream permissions. They will log prompts but not tool calls. They will track model output but not agent authority. They will call it productivity and accidentally build shadow infrastructure.

This will not happen because teams are careless by nature.

It will happen because abstraction makes the trust model feel invisible.

When everything sits behind a friendly agent interface, it becomes easier to forget that real authority is being delegated underneath. A tool call may look harmless in the UI, but downstream it may be reading data, opening tickets, modifying configuration, calling APIs, or triggering workflows that have real operational consequences.

The lazy version of agentic cloud says the agent should have whatever access it needs.

The better version asks whether we can prove the agent cannot reach what it must never touch.

That is the shift.

The agentic cloud needs deny thinking

Allow policies are necessary, but they are not enough.

Mature IAM needs both sides of the sentence.

One side says that this identity is allowed to do this specific thing.

The other side says that this identity must never be able to do that thing, even if another policy, shortcut, inherited role, or future configuration mistake tries to make it possible.

That second sentence is where deny policies, principal access boundaries, conditional access, runtime governance, and just-in-time privilege become important.

An incident-response agent may be allowed to investigate alerts, but it should not be able to disable security controls. A data analysis agent may query approved datasets, but it should not be able to export raw customer data. A deployment assistant may suggest infrastructure changes, but it should not apply production changes without human approval. A support agent may retrieve account metadata, but it should not access payment information. A security triage agent may enrich findings, but it should not modify IAM. A coding agent may open a pull request, but it should not rotate secrets or change production policies.

That is not overengineering.

That is the minimum level of discipline required once agents can touch real systems.

The real IAM maturity test

So when I ask “How is your IAM?” in a Google Cloud environment, I am not asking whether someone ticked a checkbox or enabled a feature.

I am asking whether the team can explain the trust grid.

Can they list the human principals? Can they account for the service accounts? Can they explain which workloads can impersonate which identities? Can they identify inherited access? Can they detect unused permissions? Can they remove standing privilege? Can they avoid long-lived keys? Can they reduce lateral movement?

And now, can they explain which agents exist? Can they show what each agent can call? Can they prove which tools each agent can reach? Can they deny destructive actions by design? Can they trace user-delegated agent activity? Can they shut down an agent without breaking production? Can they prove that an agent cannot chain itself into production impact?

That is the bar now.

Because the agentic cloud is not merely more automated.

It is more delegated.

And once systems begin acting on our behalf, IAM is no longer just access management.

It becomes the map of who and what we trust inside the grid.

Final thought

There is no doubt in my mind that IAM is changing shape.

It is no longer only the discipline of managing human access. It is becoming a full trust system for every actor inside the cloud. Humans, workloads, automations, service accounts, and now agents all move through the same grid of permissions, policies, resources, and consequences.

That shift is bigger than most people realise.

The companies that win with AI will not be the ones that connect every agent to every tool as quickly as possible. Speed alone is not strategy with agentic AI. Capability without boundaries is just risk moving faster.

The companies that win will be the ones that can answer the uncomfortable questions clearly.

Who is acting?

On whose behalf?

With which identity?

Through which tool?

Against which resource?

Under which policy?

With what runtime protection?

With what audit trail?

And if something starts moving in the wrong direction, how quickly can we shut it down?

So yes, my question remains the same.

How is your IAM?

But in 2026, that question is no longer only about users. Google Cloud NEXT '26 makes the shift hard to ignore. IAM now has to account for every human, workload, service account, automation, and agent that can touch your cloud.

Because ultimately, IAM matters from the standpoint of the business. It is not a configuration detail. It is the fence around the system, the map of trust, and the line between controlled delegation and quiet exposure.

A strong fence does not mean nothing can ever go wrong. It means the ordinary intruder does not walk in through the obvious gate. It means the blast radius is smaller. It means the dangerous paths are harder to reach. And it means that when someone asks who or what can access the heart of your application, the room does not have to fall silent.

Where to look if you want to follow the thread

Cat Web Services (CWS): A dashboard your cat uses to manage you

viola — Sun, 12 Apr 2026 22:58:46 +0000

CWS: Cat Web Services (meow...)

This is a submission for the DEV April Fools Challenge

What I Built

I built CWS, Cat Web Services, a fully managed cloud platform that helps cats monitor, control, and escalate issues with the humans they own.

Modern cats face serious infrastructure challenges. Humans are inconsistent. Treat delivery is unreliable. Door-opening latency remains unacceptable. Lap availability can degrade without warning. Existing cloud platforms were not designed for feline-first operations.

So I fixed that by building a platform that solves absolutely nothing.

CWS is a fake cloud console where cats can manage human behavior at scale through a suite of highly specialized services, including:

CatOps for human workforce monitoring
Identity and Meowment (IAM) for access control over petting, feeding, and sofa privileges
ClawedWatch for real-time incident monitoring
Snack Notification Service for mission-critical treat escalation
Scratch, Sleep, Store for durable storage of naps, grudges, and box-related assets
Route 9 Lives for low-latency movement between operational rooms

The platform displays totally useless enterprise metrics such as:

treat response latency
lap readiness score
sunbeam occupancy
meow acknowledgement rate
vacuum threat level
blanket warmth compliance

In other words, this is a serious cloud product for unserious cats.

My favorite part is that whenever a human attempts to access cat-only controls, the platform rejects the request with an intentional HTTP 418, because if you are going to build nonsense, you should do it with standards.

Demo

Live App: CWS Console
Source Code: GitHub Repository
Demo Video / GIF: Video demo

Code

The project is built as a fake enterprise cloud dashboard, with each service behaving like a parody of a real cloud product, except every metric is tailored to the emotional and operational needs of cats.

A few examples:

CatOps shows the current human status, including response time, usefulness, and cuddle uptime
IAM controls permissions such as can_open_tuna, can_interrupt_nap, and can_prevent_zoomies, most of which are denied by default
ClawedWatch logs critical production incidents like:
- Human entered kitchen and returned empty-handed
- Bathroom door was closed without approval
- Laptop occupied preferred sitting zone
- Vacuum detected in production

The whole product is intentionally polished enough to look real for a second, which makes the joke hit harder.

How I Built It

The inspiration came from my Sphynx cats... and the whole CWS is a frontend-first parody dashboard using:

React
TypeScript
Vite
SCSS Modules
Framer Motion

I chose this stack because it let me move fast and spend more time on the important engineering problems, such as how to represent catastrophic blanket misalignment in a way that feels enterprise-ready.

The app is structured like a fake cloud console with reusable cards, service panels, incident feeds, status badges, and absurd metric widgets. I wanted it to feel like the kind of dashboard that a very demanding cat product manager would insist on shipping before the end of the quarter.

I also leaned into the writing and naming as much as the UI, because half the joke here is the contrast between dead-serious platform language and the completely ridiculous problem domain.

A few things I focused on while building it:

making the interface feel weirdly believable
writing service names that sound close enough to cloud products to be instantly recognizable
making the metrics specific enough to feel like a real system
adding intentional 418 responses when humans attempt privileged actions

This project is proudly overengineered for a problem that should never have existed.

Prize Category

Best Ode to Larry Masinter

I intentionally worked HTTP 418 into the experience as a first-class feature. In CWS, when a human tries to perform cat-only administrative actions, the system returns a 418-style rejection because the platform recognizes that the requester is fundamentally not qualified to operate feline infrastructure.

This project is not a teapot. It is, however, spiritually adjacent.

A Year of Building snappycart in Public or 7 Mistakes I Learned the Hard Way

viola — Wed, 08 Apr 2026 23:54:34 +0000

A year ago, I thought the hardest part of open source would be building the package....

It was not.

The code mattered, of course. But building snappycart in public taught me that writing the package is only one layer of the job. The harder part is making the project visible, understandable, trustworthy, and worth coming back to. And knowing what I knew did not mean that everyone could get the same vibe and go along with it. So what actually happened? Read on!

snappycart started as a practical React cart package, something developers could integrate into ecommerce and SaaS products without dragging in a messy setup. The main reason I created it was to save money on cart and checkout integrations and I immediately saw gap there which prompted me to release my snappycart to the world. Over time, though, it became much more than a package. It became a product, a repository, a contributor space, a testing surface, and a public signal of how seriously I take quality. And this can be easily proven by how much time snappycart contributors invest in testing an developing the package. Surely anyone can release a package, but would that anyone be able to get the momentum out of contributors around it? Probably, but not instantly.

That changed how I think about open source.

Here are seven mistakes I learned the hard way that I am eager to share with you because I want our open source community to strive and produce more free solutions for all of us devs out there. Enjoy...

1. I thought publishing the package meant people would find it

This was the first big misunderstanding. Man, if I only knew...

Like a lot of developers, I assumed that once the package was live on npm and GitHub, the right people would eventually come across it. I thought the quality of the thing itself would do more of the work, just like they show us in the movies.

It does not.😬

Publishing is not distribution in the same way as shipping is not visibility. Open source is not some magical meritocracy where good code automatically floats to the top just because one day you woke up, had some coffee, sat in your wonderful London garden and DEVELOPED IT... Most people are busy, distracted, and already overloaded with libraries, tools, and repos they have not had time to evaluate. But even worse, not many devs are even considering other tools. I mean who really wants to trade some tool they learnt back in 2020 during the COVID-19, when they had the time, to something that Viola (@idncod) decided to release to 'solve' their problem? What problem?...

That means if you build something useful, you still have to explain why it exists, who it is for, and why someone should care right now and for others it's fine to pass it by.

The lesson for me was simple: if I want snappycart to grow (organically), I cannot just build it and leave it. I have to talk about it, demo it, document it, and repeat the message consistently. Otherwise it just becomes another repo in the pile and nobody gets to see those cute big odd eyes!

2. I underestimated how much people need examples

I originally put too much faith in the package API doing the talking.

In reality, developers do not want to imagine how something works. They'd rather see it working. They (actually, we!) want to know how the provider wraps the app, how state moves through the UI, what the cart drawer looks like, how quantity updates behave, and whether the integration feels smooth or annoying. You know, the sacred DEMO that we desire to play with and get to know the package.

That means examples are not a nice extra. They are part of adoption! (knowing myself too well, I must have thought about this from day one but just didn't feel the urge yet. Well, too bad.)

One of the most important shifts I made with snappycart was thinking beyond the package internals and focusing more on the actual developer journey. A demo app, realistic usage flows, and clear visual examples do far more than a technically correct API description on its own.

A lot of open-source projects lose people because they make users do too much interpretation which is a big mistake. Imagine if someone has to mentally assemble your product before they can trust it, you are already asking for too much without providing any value upfront.

3. I treated docs like support material instead of part of the product

This is such an easy trap. And I am glad I get it now.

At the start, it is tempting to think: let me finish the code first, then I will polish the docs later. That sounds reasonable, but it is wrong.

For most users, the docs are the first product they touch.

They are not meeting your architecture first. They are meeting your README, your install instructions, your project structure, your usage examples, and the speed at which they can get to their first success. If that experience feels messy, the whole project feels messy.

Working on snappycart forced me to take documentation more seriously, not as a cleanup task but as part of the interface. The docs are where confidence starts. They are where people decide whether this project feels maintained, understandable, and safe to try.

Bad docs do not always create loud complaints. More often they create silent drop-off, which is worse.

Now that I have made some drastic changes to my README in the latest version 1.2.3, I am over the moon to hear from my contributors and people who see my product for the first time things like: 'Well, this README is actually well-structured and it's very easy to understand how I can contribute' (-Zinaida, contributor) and 'The README is so detailed that I can tell what I am dealing with' (-Jay Saadana).

4. I assumed contributors would just figure the repo out

That was naive.

If you want contributions, you have to design for contribution. People need a way in. They need to understand the structure, the setup, the workflows, the standards, the frameworks, and the straightforward release process. They need to know where the package lives, where the demo app lives, how to run tests, what sort of changes are welcome, and how not to break everything.

A public repo is not automatically a collaborative project. It only becomes collaborative when it is legible.

That was a big lesson for me with snappycart. The more I thought about contributors seriously, the more obvious it became that open source is not just about making code available. It is about reducing the friction of joining the effort. If you're into React or Nextjs, join us on Telegram and help us build a better tool!

Good contributor experience is not accidental. It is engineered.

5. I underestimated how much release discipline matters

This one became way more obvious over time.

It is easy to think the main signal of progress is writing new features. But in open source, release hygiene matters a lot more than many people admit. Versioning, changelogs, package structure, visible updates, and a clean release process all shape how serious the project feels.

People do not just look at what your project can do. They look at how it moves.

When a package has chaotic releases, unclear versioning, or no visible update trail, it feels unstable. When it has structure, clear releases, and a proper rhythm, it feels alive and trustworthy.

That matters because open source is not just consumed technically. It is judged operationally too.

With snappycart, I learned that keeping the package, demo, docs, and release flow aligned is part of the product experience. It tells people this is not abandoned, not random, and not being held together with luck.

6. I thought momentum would take care of itself

It does not. Momentum is fragile.

Even if good work is happening, the project can still look dead from the outside if there is no visible cadence. No updates. No release notes. No discussion. No signs that someone is actively steering the thing forward.

That was a hard lesson because silence can erase progress very quickly.

Open source needs continuity. Not fake hype, not constant noise, but rhythm. Small updates. Honest posts (like this one). Improvements people can actually see. A sense that the project is being maintained with intent rather than occasional bursts of energy.

For me, this also reinforced that community is not built off one good week. It is built through repetition and over time.

7. I started by thinking like an engineer instead of a maintainer

This is probably the biggest lesson of the whole year.

An engineer asks whether the package works.

A maintainer has to ask much more than that.

Can people understand it fast? Can they trust it? Can they integrate it without pain? Can they contribute without feeling lost? Can they tell whether the project is healthy? Can they see where it is going?

That mindset changes everything.

With snappycart, I started to see that the project was not just a code artifact. It was also a public product, a contributor surface, a QA playground, and a reflection of how I build things in the open. That means the responsibility is bigger than "it works on my machine" or even "the API is clean."

Maintaining open source properly means owning the whole experience around the code, not just the code itself.

Closing thoughts

A year of building snappycart in public taught me that open source is not just about writing useful software or having the complete remedy to all the devs' problems.

It is about making that software understandable, visible, maintainable, and easy to trust. Trust is the part that so many top quality npm packages are missing even if they have an excellent testing suite in place.

Some of the hardest lessons were not about engineering in the narrow sense. They were about discoverability, examples, contributor clarity, release discipline, documentation, and consistency. Those are the parts that often look secondary at the start, but in practice they shape whether a project actually grows.

One thing I am glad I took seriously early was testing and quality. But even that fits the bigger pattern: the strongest open-source projects are not just built well. They are presented well, maintained well, and made easy for other people to believe in.

That is the standard I want snappycart to keep growing into.

If you are building in open source right now, my advice is simple: do not just ship the package. Build the path around it too.

How to secure MCP tools on AWS for AI agents with authentication, authorization, and least privilege

viola — Sun, 05 Apr 2026 01:28:10 +0000

Model Context Protocol (or MCP) makes it easier for AI agents to access your existing backend capabilities. It allows AI agents to have access to your system's call services and to use tools such as Lambda functions. That convenience comes with a huge trade-off, a raised bar for security, because it demands a much stronger access model around those interactions. The problem is that once an agent can reach tools, you should be questioning who is calling what, on whose behalf, with which scope, through which boundary, and, most importantly, how to stop the whole thing from becoming an overprivileged mess and ruining the experience for real humans using your product.

The issue is clearly there and AWS is already building for this through Bedrock AgentCore Gateway and AgentCore Identity, while the MCP roadmap is moving in the same direction with enterprise-managed auth, audit trails, gateway patterns, and more fine-grained least-privilege scopes.

But authentication is no longer the main event, even though a lot of teams still treat it like it is. Because authentication answers who got in, authorization answers what they can do, and least privilege answers how much damage is possible when things go sideways. And here it is very important to think in layers as in MCP-based agent systems, you usually need all three at multiple layers; inbound authentication to the agent or gateway, outbound authentication from the gateway to the tool, and policy decisions on whether a given tool call should be allowed at all. AWS's current guidance reflects that layers split. Moreover, their product model is literally built around those layers and that exact order. For instance, AgentCore Gateway supports inbound OAuth-based authorization for incoming tool calls and multiple outbound authorization modes depending on target type, including IAM-based auth with SigV4, OAuth client credentials, authorization code grants, and API keys. We will be diving deeper into this later in this article.

So why does MCP change the ways we should think about security?

For the good part, because it gives AI agents a standard way to reach tools, services, and execution paths that sit outside the model itself. Once that access exists, the problem stops being just about connectivity and starts becoming an access-control problem, since you need to know who is calling which tool, under what identity, with which scope, and across which boundary.

That gets messy quickly when the same system has to support both user-delegated actions and machine-to-machine actions. Without a tight identity model, agents can end up with broad standing access, weak separation between human and non-human callers, and very little control over how requests move from one system to another.

This is where the AWS model starts to make sense. Bedrock AgentCore Gateway gives you a controlled entry point between agents and tools, while AgentCore Identity adds a dedicated layer for identity and credential handling for agents and automated workloads. The direction of the MCP ecosystem also reflects that reality, with current roadmap priorities including enterprise-managed auth, audit trails, gateway patterns, and more fine-grained least-privilege scopes.

The security model I'd use on AWS if I was setting it up today

The cleanest way to secure MCP tool access on AWS is to stop treating it as one big authentication problem. In reality, it breaks down into four separate control layers: inbound authentication, outbound authentication, authorization, and infrastructure-level least privilege.

That split matters because an MCP tool call is not a single trust decision. First, you need to control who is allowed to reach the agent-facing layer. Then you need a safe way for the gateway or runtime to authenticate downstream to the target tool. After that, you still need to decide whether the exact action should be allowed in context. Finally, the underlying AWS roles, scopes, and permissions need to stay narrow enough that a mistake in one layer does not turn into broad access everywhere else.

This is the structure I find easiest to reason about while still keeping it close to how these systems behave in production on AWS:

First, inbound authentication for the caller.
Second, outbound authentication for downstream tool access.
Third, authorization for the action itself.
Fourth, least privilege for the infrastructure underneath it always.

Breaking it down like that gives you a much cleaner outline of the problem before even starting the implementation.

Number one: Inbound authentication to the agent-facing layer

The first control point is the agent-facing layer itself. Before an agent can reach a tool, you need to decide who is allowed to invoke the gateway or runtime in the first place.

On AWS, AgentCore Gateway follows the MCP authorization model for inbound requests and can validate incoming calls against an OAuth provider such as Amazon Cognito, Okta, Auth0, or another compatible provider. That gives you a clear front-door identity check before any downstream tool access happens. AWS also supports different inbound flows depending on the caller, including authorization code flow for user-delegated access and client credentials for service-to-service access, with the ability to restrict access by approved client IDs and audiences.

Distinct between types of calls matters for a very good reason which is all MCP calls represent a different kind of trust. Some calls may come from a signed-in user acting through an application, while others may come from a background service, automated workload, or non-human agent, where this gets so complicated that it can get out of hand in production to the point where it will require more resources to fix it than to set it up correctly from the start. That is why all of these different types of calls must never be treated as equivalent, because not only do they not carry the same identity context, but also they carry a completely different level of user intent.

This is where it starts to snowball into a problem because when every inbound caller gets labelled as authenticated, the distinction between a human user session and a machine credential vanishes. But if we were to design a much safer model from the beginning, a smart choice would be to keep the concerns separated. For example, all user-delegated access will be done using authorization code or PKCE, while any machine-to-machine access will involve client credentials.

Number two: Outbound authentication from the gateway to the tool

This is usually the point where things start getting messy. A team does a decent job on inbound authentication, then quietly lets the gateway or agent call downstream tools with whatever credentials happen to work. That might get the system running, but it is not much of a security model.

Outbound authentication needs to be treated as its own control layer. Once the gateway, runtime, or agent starts talking to tools, APIs, or MCP servers, it still needs a clear and deliberate way to prove its identity to those downstream targets.

AWS separates that part properly. Depending on the target, AgentCore Gateway can use IAM-based authorization with a service role and SigV4, OAuth flows, or API keys. For MCP server targets, OAuth client credentials are supported as well. That matters because not every downstream target should be trusted in the same way, and not every tool should accept the same type of credential.

This is also where AgentCore Identity starts to become genuinely useful. Instead of scattering tokens, secrets, and auth logic across runtimes, tools, and bits of glue code, you can centralize that machinery in a service designed for agent identity and credential handling. That is a much cleaner setup, especially once the number of tools starts growing.

The main thing I would avoid here is treating downstream access as an implementation detail. It is not. If the gateway or runtime can call tools, then the way it authenticates to those tools needs to be deliberate, narrow, and easy to reason about.

Number three: Authorization inside the application path

Being authenticated does not automatically mean being allowed to use every tool or perform every action. That sounds obvious, but this is exactly where systems start to drift. A token is valid, the request gets through, and before long the system is treating "known caller" as if it means "allowed to do whatever comes next."

That is why I would treat authorization as its own layer. Once the caller is authenticated and the gateway can reach the tool, the system still needs to decide whether the specific action should be allowed in that context.

Cognito gives you a good starting point for broad API permissions through resource servers and custom scopes. That works well when you want to express coarse-grained capabilities such as billing.read, orders.update, or reports.export. It gives you a cleaner way to separate what a token can generally do from who the caller is.

But scopes only get you so far. The moment the decision depends on tenant membership, resource ownership, role, environment, or some other piece of context, you are no longer dealing with simple scope checks. You are in fine-grained authorization territory.

That is where something like Amazon Verified Permissions starts to make more sense. Instead of burying authorization logic across handlers, services, and bits of application code, you can move those decisions into a more explicit policy layer. That tends to be easier to reason about and much easier to change later without creating a mess.

The split I would use will pretty much reflect that:

Firstly, I want authentication to establish identity, my OAuth scopes will establish broad capabilities, whilst policy checks will be the decision-making body on whether the exact action should be allowed in context. And that separation is much healthier than trying to force every decision into token validation or scope checks alone because not everything can be solved a token.

Number four: Least privilege for the infrastructure layer

Even if the identity and authorization layers look good on paper, the system is still weak if the underlying roles and permissions are too broad.

This is the part teams often underestimate. They spend time on tokens, OAuth flows, and gateway design, then quietly give the runtime or supporting services far more access than they actually need. At that point, the front door may look secure, but the blast radius behind it is still too large.

Least privilege matters here because MCP-based systems usually involve several moving parts: the gateway, runtimes, identity services, tokens, and the downstream AWS APIs or tools those components need to reach. If one of those layers is over-scoped, the whole system becomes easier to abuse.

AWS's own AgentCore examples point in a much healthier direction. In the FinOps agent architecture, the gateway uses IAM authentication to call runtimes, AgentCore Identity handles the OAuth credential lifecycle, and Cognito client credentials are used so the gateway can obtain tokens for MCP runtimes. The runtime roles themselves are then scoped to the AWS APIs they actually need, such as billing or pricing. That is a much better model than handing the entire agent stack one broad role and hoping the application layer keeps everything under control.

In practice, least privilege here means a few simple things:

the gateway role should only have permission to invoke the specific targets it actually needs
MCP runtimes should only have access to the AWS APIs required for their own domain
tokens and scopes should stay as narrow as they can while still allowing the system to work

The same applies to flow selection. If you use the wrong OAuth flow for the wrong kind of caller, the access model gets messy very quickly. Keeping human and non-human access paths separate from the start makes it much easier to keep scopes, roles, and permissions under control later.

Where Cognito actually fits in this design

Cognito is useful in this design, but it is not the whole story.

It fits well at the front of the system when you want an OAuth provider for inbound gateway authorization, especially if you want familiar OAuth flows, JWT validation, app-client control, and support for machine-to-machine access through client credentials. That makes it a practical option when the gateway, agent, or MCP runtime needs token-based identity rather than a human session.

Where people get confused is assuming Cognito solves the whole access model on its own. It does not. It can help establish identity and broad access boundaries, but it does not automatically solve downstream tool authentication, cross-system credential handling, or fine-grained authorization decisions.

That is why I see Cognito as one building block in the overall design, not the design itself. It works well for inbound identity and token issuance, but once you move into downstream credentials, agent-to-tool access, or context-heavy policy decisions, you need other layers around it. That is where services like AgentCore Identity and a proper authorization layer start to matter much more.

Don't ignore private connectivity

If your gateway or tool layer is reachable over the public internet by default, you are increasing exposure before you even get to identity or policy. That does not automatically make the design wrong, but it does mean you need to be much more deliberate about where your control paths actually live.

Private connectivity is not the whole security model, but it should still be part of it. Once you have agents, gateways, policy services, and downstream tools talking to each other, it makes sense to keep the more sensitive service-to-service paths inside private network boundaries where you can. That reduces unnecessary exposure and gives you a cleaner production shape around the parts of the system that matter most.

It is also worth being clear about what private connectivity does and does not solve. It does not replace authentication, authorization, or least privilege. It does not make a bad access model good. What it does do is reduce the attack surface and make those identity and policy controls easier to enforce within tighter boundaries.

So I would treat private connectivity as a supporting layer in the design: not the main event, but definitely not something to bolt on at the very end either.

A practical reference architecture

If I were putting this together for a real team, the shape would be fairly straightforward.

A user signs into the application through Cognito or another OIDC provider, and the application calls the agent-facing layer with a token that matches that user journey. AgentCore Gateway then validates the inbound token and checks that the client and audience are actually allowed. From there, downstream tool calls use the auth mode that makes sense for the target, whether that is IAM SigV4 for AWS-native targets or OAuth client credentials for MCP runtimes and APIs.

AgentCore Identity handles the OAuth client setup and token retrieval so that each component does not have to manage its own secrets and token logic. On top of that, the application or policy layer still needs to decide whether a sensitive action should be allowed, ideally using narrow scopes and more fine-grained rules where the context matters. Underneath all of that, the IAM roles for the gateway and runtimes should stay tightly scoped to their real responsibilities.

That is much closer to a production-grade setup than the very loose model where an agent has a token and can just start calling things.

The mistakes I would actively avoid

The first mistake is using one broad machine credential for every tool call. Inbound access and outbound access are not the same thing, and different targets should not automatically inherit the same trust model. Once one credential starts working for everything, the system gets convenient very quickly and safe very slowly.

The second mistake is mixing user-delegated access with autonomous machine access without being explicit about the difference. Authorization code and client credentials exist for different reasons. If you blur those paths together, it becomes much harder to tell who actually authorized the action and what kind of trust you are relying on.

The third mistake is assuming JWT validation equals authorization. It does not. Token validation tells you the token is valid. It does not tell you whether the caller should be allowed to perform a specific action on a specific tool or resource in the current context. That gap is where a lot of bad access decisions get hidden.

The fourth mistake is relying on static secrets when a managed OAuth or IAM-based pattern is available. Static credentials tend to spread, linger, and get reused in places they should not. The more agent and tool integrations you add, the worse that gets.

The fifth mistake is treating networking as irrelevant. Identity and authorization matter more, but that does not mean network boundaries stop mattering. If you can keep sensitive control paths private, you should. It is a sensible extra layer, especially once you have multiple services making sensitive calls to each other.

The common thread across all of these mistakes is pretty simple: they make the system easier to build in the short term, but much harder to trust later.

The dangerous version of an AI agent is not the one that can call tools. It is the one that can call tools with vague identity, broad standing access, and no policy boundary.

Final take

Once AI agents can reach tools, the security model has to get more serious. At that point, this stops being just an integration problem and becomes an access-control problem across identity, credentials, authorization, and least privilege.

AWS already gives you the right building blocks to design for that more deliberately: Cognito for inbound identity, AgentCore Gateway for controlled MCP tool access, AgentCore Identity for agent credential handling, IAM for scoped AWS permissions, and Verified Permissions when broader token scopes are no longer enough.

The main thing is not to collapse all of that into one vague idea of "auth." Authenticate every boundary, authorize every sensitive action, and keep every identity and permission narrower than feels convenient. That is the difference between an agent system you can trust and one that only looks tidy until something goes wrong.

If you're working on securing agent tool access on AWS, I'd be curious to hear how you're handling inbound auth, downstream credentials, and policy checks in practice.