Access Management shouldn't be an afterthought in your Internal Developer Platform

Introduction

One common challenge that all Internal Developer Platforms (IDP) will reach at some point is how to handle access management. Who should be able to request self-service resources? Who should own the solutions that are requested? How should members be onboarded and offboarded? In this blog post I will introduce the concept of Team Boundary as a first-class citizen as a way to solve these challenges, with examples from how we have done it at our client.

The Challenge

At our client we have self-service solutions for many different types of resources: GitHub repositories, Kubernetes namespaces, databases, Azure Subscriptions, among others. These solutions exist so developers can quickly get ready-made environments and start doing what matters: writing code. As a platform team we want to avoid being blockers and ensure that new projects and features can be delivered quickly.

However, we do not want to tie these resources to individual users. That would make it time-consuming for developers to onboard and offboard members to each individual solution — wasted time from both a developer and business perspective. We also don't want the platform team to micromanage members. We do not have full insight into who should have access to what, and at some point managing access would become at least a full-time job. The security risk of improperly offboarded members compounds over time. And of course, granting everyone access to everything is never a solution.

What is a Team Boundary?

A Team Boundary is a named team identity that serves as a prerequisite for provisioning any platform resource. It is a first-class citizen — built into the core of the platform, not an afterthought. It is the first resource a developer must have before they can request anything else.

How it works in practice

The Team Boundary is where it all starts. Before a developer can create anything, they need to either be a member of an existing Team Boundary or create a new one. At our client we use Azure Entra ID as the identity provider, so this was a natural place to start. When a developer requests a new Team Boundary the automation does the following:

• Creates an Entra ID group: The members of this group will automatically get access to all resources related to the Team Boundary

• Adds the requestor as a member of the group: It's assumed that the requestor will need access to the resources, so the requestor is automatically added as the first member

• Adds the requestor as an owner of the group: The requestor will be responsible for onboarding and offboarding members to the group

• Adds a scheduled Entra ID access review for the group: This acts as a reminder for the owner to evaluate who should continue to have access

Now the developer has a Team Boundary. This serves as an input for all other resources the team will need. To request a Kubernetes namespace, the developer provides their Team Boundary as input. The automation takes the Team Boundary (the Entra ID group) and grants it the necessary access to operate resources inside the namespace and all its supporting resources. The same applies to databases, additional repositories, and any other resource — the automation wires up access automatically.

The Entra ID group is the single source of truth. Everything else is a projection of it: the GitHub Team is synced from the group, Grafana directories are provisioned automatically, Azure resources grant access to the group directly. Developers can't create orphaned access — they cannot manually create a GitHub team and add whoever they want. All access flows through the Team Boundary, enforced by automation. When the team needs to onboard a new member, the only thing they do is add that person to the Entra ID group.

What this unlocks

This model follows a key design principle: coarse-grained control, fine-grained autonomy. The platform is strict about who belongs to a team, but relaxed about what team members can do within their space. Once inside, teams have meaningful autonomy — free rein in their Grafana directory, and the access they need to operate within their GitHub repositories and namespace.

This is fundamentally different from traditional IT access management, where both membership and permissions are tightly controlled centrally. It also means that even if a team goes off the golden path for some resources, their identity and access still flows through the same boundary.

Yes, some developers may not need all these resources — that is an accepted trade-off. The alternative is micromanaging access control, which becomes more complex and fragile than simply managing members of one group.

While our example uses Azure Entra ID, the concept is platform-agnostic. In AWS you would map this to IAM Identity Center groups; in GCP to Google Groups. The implementation differs, but the principle — one team identity primitive that everything else flows from — holds regardless.

Key decisions

Every organization will have different requirements around the Team Boundary. Key questions to ask:

• Who should be able to be owners of the Team Boundary? Should it be project leaders, only internal employees, any developers?

• Should we allow multiple owners of the Team Boundary? Or should we have a process for handling onboarding / offboarding if the owner is not available?

• How often should an access review be scheduled? What should the default action of an access review be?

• How do we communicate the responsibilities to owners of the Team Boundary?

• How do we grant the Team Boundary access to what they need and not more?

Conclusion

Access management is one of those things that feels easy to defer — until it isn't. By treating the Team Boundary as a first-class citizen in your IDP, you give your platform a stable identity primitive that scales with your organization. Onboarding new members becomes a single operation. Offboarding is equally simple, and the security benefits compound over time. The platform team stays out of the business of micromanaging access, and developers retain the autonomy they need to move fast.

The right time to introduce this concept is at the start, before self-service resources multiply and access management becomes a tangled mess to untangle. But even if you're further along, the Team Boundary is worth introducing — the earlier the better.