Authentication was a breeze. Ownership and trust were harder and led to domain-driven decisions.
TL;DR
Machine Authentication ≠ Trust.
A machine can authenticate successfully and still be the wrong identity for that context.
The real challenge is detailing ownership, tenant boundaries, lifecycle, and trust in a structured way.
The identity problem changed early
Multi-tenancy was never optional for us.
The platform needed strong tenant isolation, clear ownership boundaries, and security rules that could scale across organizations and workflows.
That requirement shaped identity decisions very early.
In a single-tenant app, authentication and authorization are often enough to get started.
In a multi-tenant platform, every access decision eventually becomes a boundary decision.
You start asking questions like:
- Who owns this resource?
- Which tenant created this data?
- Which tenant is this identity acting inside?
- Should this action be allowed across tenant boundaries?
That is where permissions alone stop being enough.
A role tells you what an identity/principal can do.
Tenant context tells you where it can do it. For us tenant was a trust/security boundary out the gate.
Both matter.
Our first model worked for day-to-day users
The first version of the system was centered around people.
- Users authenticated. ✅
- Claims carried context. ✅
- Roles grouped permissions. ✅
- Scopes represented allowed actions. ✅
- Authorization rules decided whether a request could access a protected resource. ✅
A simplified early claim looked like this on paper:
{
"sub": "user_123",
"tenant": "tenant_a",
"roles": ["analyst"],
"scopes": ["read.records", "write.records"]
}
That model worked well because ownership was usually obvious.
A principal belongs to a tenant.
A request carries tenant context.
Policies can evaluate permission and boundary together.
For your standard day-to-day users, that assumption held up well enough.
And in hindsight, that phase was useful and beneficial as a base to jump from.
It forced us to think carefully about roles, scopes, claims, and tenant boundaries before machine identities entered the picture.
The moment machine identity stopped fitting
It was immediate (no building tension here). The first machine credential forced us to revisit one of our earliest assumptions:
tenant ownership is obvious.
A machine identity might belong to:
- a tenant
- the platform itself
- a specific runtime
- an internal service
- an external integration acting on behalf of a tenant service accounts
- and now autonomous agents acting with minimal guardrails on behalf of tenants AI
That was the point where the model started to feel incomplete or that the linear pathway was insufficient.
At first, machine identity looked like a simple extension of what we already had.
Scopes still mattered.
Claims still mattered.
Authorization still mattered.
Duh ... in many ways it did.
So it was tempting to treat a machine identity as just another principal entering the same policy engine that was running our authz.
A principal identity is usually tied to a person.
A machine identity is tied to a responsibility and bounded operational context for us AND the tenant using it. That changes the design.
Multi-tenancy made the gap obvious
Once machine credentials became first-class actors in the system, the questions changed into a more governable lens.
We also had to ask:
- Who created this credential?
- Who owns it?
- Which tenant does it belong to?
- Can it act across tenant boundaries?
- Which runtime is allowed to use it?
- How is it rotated?
- How is it revoked?
- How do we audit it later? ... there were more..
Those aren't just authentication questions.
They are ownership questions, lifecycle questions, and trust questions.
It stopped looking like an auth extension and started looking like a domain model by design.
Authentication and trust are not the same thing
This was probably the clearest takeaway.
At the protocol level, machine-to-machine auth can look straightforward (and is here):
- issue a credential
- validate it
- check claims
- evaluate policy
But a valid credential can still be the wrong credential.
A signed token can still represent an identity being used outside its intended boundary. A client can authenticate successfully and still be operating in a context the platform should not trust.
That is why this distinction became important:
Authentication ≠ Trust
Authentication asks:
Can this identity prove something about itself?
Trust asks:
Should this identity be allowed to act here, in this context, under these ownership boundaries?
That second question is bigger. And it gets bigger as machines become more autonomous.
The most important question: who owns this credential?
This ended up being the most useful question in the whole space:
Who owns this credential?
Because once that is clear, a lot of other things become easier to define:
- tenant scope
- allowed actions
- allowed runtimes
- lifecycle rules
- revocation behavior
- audit expectations
- trust level
And if that answer is unclear, the model is probably still too loose. It largely drove us deeper into domain-driven architecture designs and subsequent decisions early.
That is why I now think machine identity in a multi-tenant platform is really an ownership problem first.
Trust is the consequence of getting ownership right. Of course, this starts to lean into governance and security frameworks. But my goal here is less about prescribing a framework and more about sharing the mental model that helped me reason about the problem.
What made this exciting was how early this IAM / M2M complexity showed up as a real product requirement. That was new for me in pacing, and it forced more mature identity and access patterns across the runtimes involved (all of them lol).
A simple mental model that helped me
If I had to compress the lesson into one simple framework, it would be this:
Human identity:
principal → tenant → permissions
Machine identity:
responsibility → owner → tenant boundary → trust → permissions
It's simplified, but it captures the shift well enough.
For humans, identity usually begins with the person and their relationship to a tenant.
For machines, identity becomes meaningful through ownership and boundary.
Final thoughts
The real design pressure was deciding what a machine identity actually means inside a multi-tenant platform.
- Who owns it?
- Which boundary does it belong to?
- What is it allowed to represent?
- Why should the platform trust it in this context?
In multi-tenant systems, machine identity must be about modeling trust.
Tags: #m2m #security #architecture
Quick glossary
Machine identity
Machine identities are digital entities used to identify, authenticate and authorize machines. What is a Machine Identity
Multi-tenant platform
Also called software multitenancy, a single instance of a software application serves multiple tenants (or user accounts). The identity problem changed early
Tenant
A customer, organization, or isolated account boundary inside a multi-tenant system.
Principal
A single identity recognized by a system, such as a user, service, or machine identity.
Credential
Object, doc, or structured data used to prove identity, such as an API key, token, client credential, or similar authentication secret.
Claims
Pieces of identity-related information carried with authentication data, such as tenant, role, or subject. What are claims?
Scopes
Named permissions that define what an identity is allowed to do. Scopes vs Claims
Runtime
A runtime, in general, executes a piece of software. What is runtime?
Trust boundary
A system boundary where identity, ownership, and context must be evaluated before access should be allowed.
Top comments (0)