Imagine your building has a master key. Everyone on the security team uses the same key to get in. When something goes missing, you check the access log — and it says “Security Team.” Not who. Just the team.
That’s what we had on our cloud servers.
The Problem in Plain Language
When someone on our team connects to a server in AWS, they use a tool called Session Manager — think of it as a secure remote control for servers. No passwords, no special keys. Clean, audited, controlled.
The problem: no matter who connects, the server sees them all as the same person. A shared account called ssm-user. Like everyone entering through the same door wearing the same badge.
When an auditor asks “who changed that file on that server last Tuesday?” — we couldn’t answer. Not specifically. We could say which team had access. Not which person.
That’s a problem for compliance. It’s a bigger problem when something actually goes wrong.
What We Needed
We needed each person to arrive as themselves. Alice connects — the server sees Alice. Bob connects — the server sees Bob. Their permissions come from their role in our identity system (Microsoft 365, the same place we manage everyone’s email and logins). When Alice changes teams, her access changes automatically. No one has to update anything on the server.
Sounds simple. It wasn’t.
Why It Took Weeks to Even Find the Answer
The technology to do this exists. AWS has it built in. But the documentation only covered how to set it up with a different identity system (Okta). We use Microsoft’s identity system (Entra ID).
We searched. We opened a support case with AWS. They tried. Genuinely. But the answer sat at the intersection of three different AWS systems and Microsoft’s systems simultaneously — and no single team owned the full picture.
Weeks passed. We started wondering if we were the only ones who needed this.
We weren’t. We were just the first to document it for the Microsoft world.
How We Solved It in a Day
We used an agentic AI system — not a chatbot you type questions into, but an autonomous assistant that works directly in our development environment like a skilled colleague.
The key difference: instead of one person reading one document at a time, the AI ran parallel research teams across the entire internet simultaneously. AWS documentation, Microsoft documentation, community forums, developer blogs, obscure support threads from three years ago — all at once, cross-referenced, synthesised into a complete picture.
But it didn’t just research. It planned. It wrote the technical solution. It reviewed its own work — not once, but across five different quality dimensions. It caught its own mistakes before we ever saw the output. It documented everything as it went.
Two hours of research. Then planning, building, testing, and documentation — all in the same day.
What We Delivered
Two options, depending on what a team needs:
Simple version: People connect to servers and land as their job role — “developer”, “admin”, “support”. The server sees the role, not the person. AWS still records who it actually was. Works everywhere, no extra setup.
Full version: People connect and the server sees them personally — Alice as Alice, Bob as Bob. Their permissions come automatically from their team membership in our company directory. Move Alice to a different team, her server permissions update on their own.
Both options enforce this across the entire organisation automatically. New servers, new accounts — they all get the policy pushed to them without anyone having to do it manually. And nobody in a member account can turn it off.
What This Means for the Business
Compliance: When the auditor asks “who ran that command?” we have an answer. A name. Not a team.
Incident response: When something goes wrong, we know who to talk to. Immediately. Not after hours of digging through logs.
Offboarding: Someone leaves the company — they’re removed from the directory — they lose server access. Automatically. No ticket required, no manual cleanup.
New starters: Someone joins — they’re added to the right team in the directory — they have the right server access. No separate provisioning step.
The Bigger Story
One engineer solved this in a day. The same problem had been open for weeks.
The difference wasn’t working harder. It was using an AI system that could hold the full picture of a complex problem simultaneously — and that applied the same rigour a strong engineering team would: formal requirements, peer-reviewed plans, test-driven development, adversarial review.
The engineer wasn’t replaced. They were elevated — freed from the detail work to make the judgment calls that actually mattered. Which requirement to prioritise. Which design approach to choose. When “good enough” was actually good enough.
That’s the right model for AI in engineering. Not replacement. Elevation.
The technical details are in the white paper. The short version: it works, it’s documented, and the templates are ready for any organisation running Microsoft 365 and AWS to adopt.
Even this post was written in the Conductor and Orchestra model — the engineer set the direction, the AI drafted and refined.