Enterprise deployment: SSO, SCIM and surviving the security review

The technical work of deploying an AI coding tool into a large company takes about a week. The security review takes a quarter, because nobody prepared for it and every answer has to be chased.

The questions are predictable. Almost all of them have boring answers. Knowing them in advance is most of the job.

Identity is not optional and not interesting

Nobody at a company with more than a few hundred engineers is creating separate accounts. The identity provider is the source of truth and everything federates to it.

SSO via SAML or OIDC. OIDC where you have the choice - it is a cleaner protocol and the integrations break less. SAML because a large share of enterprise identity providers still lead with it and you do not get to pick.

SCIM for provisioning. This is the one people skip and then get caught by. Manual deprovisioning is an audit finding, every time. When someone leaves on a Friday, their access should be gone on Friday, without anyone remembering to do it. SCIM is how that happens automatically.

Groups mapped to roles. Access should follow the group membership that already exists in the directory. If granting access means a separate administrative step in a second system, it will drift, and the drift always goes in the permissive direction.

None of this is interesting engineering. All of it is mandatory, and it is a solved problem - use an identity platform rather than building it.

Where the model runs decides the conversation

The single question that resolves the most objections: does data leave our cloud account.

Running through your own cloud - Bedrock on AWS, Vertex on Google Cloud - means requests stay inside an account the customer already owns, already has a data-processing agreement for, and already monitors. The security team has already approved that boundary for other workloads.

That reframes the review from “we are approving a new vendor” to “we are approving a new workload in an environment we already trust”, and those are radically different amounts of process.

Know the trade-offs honestly: region availability differs, the newest models sometimes land on the first-party API first, and quota behaves differently. Say so early. A limitation disclosed up front is a constraint to plan around. The same limitation discovered during a pilot is a credibility problem.

What the review will actually ask

Have these written down before the meeting:

• What is sent, and when. Which parts of the codebase leave the machine, on what trigger, and what never does.
• Retention. How long anything persists and who can read it.
• Training. Whether inputs are used to train models. Get this precisely right; it is the question everyone cares about most and the one people are vaguest on.
• Residency. Which region processes the request, and whether that is configurable.
• Audit. What is logged, for how long, and whether it exports into the SIEM they already run.
• Revocation. How access ends, how fast, and whether it is automatic.
• Blast radius. What the tool can reach, and what stops it reaching further.

The last one is where AI tooling differs from ordinary software, and where a thoughtful answer buys the most credibility. A tool that can run arbitrary commands is a different risk profile from one that only suggests text, and pretending otherwise insults a security team that already knows the difference.

Scope, then gate

Two controls carry most of the weight.

Scope tools to roles. Not everyone gets everything. A tool that is absent cannot be misused, which is meaningfully stronger than a tool that is present and permission-checked. Deny by default, so the one capability nobody thought about is unavailable rather than available.

Gate the irreversible. Anything published, anything touching money, anything with no undo waits for a person - enforced by the system, not by an instruction in a prompt. A rule that can be argued out of the context was never a rule.

Say this plainly in the review. It is the answer to “what stops it doing something catastrophic at 3am”, and having a real answer rather than a reassurance changes the tone of the whole conversation.

Bound the spend

Agents can loop, and a loop against a metered API is a bill. This is a genuinely new failure mode - traditional software does not decide to retry something three hundred times because an error message was ambiguous.

Hard ceilings per user, per team, per day, enforced server-side. When a limit is hit, stop and surface it rather than degrading quietly to something cheaper. Finance asks this question eventually; better to have answered it first.

Pilot with the sceptics

The instinct is to pilot with the team most excited about it. That produces a glowing report nobody believes.

Pilot with a team that has real constraints - regulated, legacy codebase, sceptical tech lead. If it works there, the rollout argument is already made. If it does not, you have learned that in a pilot rather than after a company-wide launch, which is the entire point of running one.

What to read next

• Auth for agents - the identity model in detail.
• Approval gates - designing the control the review will ask about.
• Rolling Claude Code out to a team - what happens after the review passes.