Building an enterprise security suite
for AI Hub

Research: mining the evidence that already existed

Without direct access to enterprise IT teams, I mined 3 years of Slack presales logs, Zendesk tickets, customer call notes, and internal support threads as our primary research corpus.

Primary research: in the users' own words

I sat in on presales and support calls and interviewed internal Solution Engineers. These quotes shaped the design most:

How other vendors solved this

I audited how the intelligent document processing market handles enterprise identity, then widened the audit. In most deals, buyers also compared us to the IAM model they already had from their cloud provider.

Data as of February 2026

What the analysis changed

The frameworks that shaped my thinking

I could not design this credibly by reading competitor screenshots. Enterprise identity is governed by published specifications and audited against named control frameworks, so I worked from the primary sources and turned what I learned into my own checklists for designing in this domain.

The checklist I designed against

Specifications tell you what is possible; audits tell you what is required. Neither tells you what to check as a designer. So I reduced everything above into two working checklists of my own — one I run before designing anything in this domain, one I hold the finished design to before I call it done. I still use both.

These two lists came out of the 22-issue log and the specifications above — most items exist because something in that log went wrong for a real customer. They travel with me to any product where identity, permissions or credentials are involved.

Building the IdP field matrix

Every identity provider names the same three fields differently. Entra calls the ACS URL a "Reply URL"; Okta calls it "Single Sign On URL"; AD FS calls it the "Relying Party SAML 2.0 SSO service URL". Admins were transcribing values between two tabs and guessing.

I built the full cross-reference matrix for all 8 supported IdPs and turned it into an in-product content requirement: the configuration UI names the field the way the admin's own IdP names it, not the way the SAML spec does.

Benchmark: what "enterprise-ready" means

Before designing screens I wrote down the standard an enterprise security review measures a SaaS product against. This became the scoring sheet the team used to decide what was in scope, what was deferred, and what we were consciously accepting as a gap.

Naming the red rows explicitly made the matrix usable in sales conversations. Presales could finally answer "do you support X?" without guessing.

Mapping three pillars into one system

Three tracks landed in the same settings area over the releases. Without a deliberate structure, AI Hub would have ended up with three unrelated "security" screens built by three different teams. That's how enterprise settings usually rot.

The structure I set

• SSO Logins: how users get in: password sign-in policy, MFA.
• Identity & access: SSO configuration, test mode, OAuth provider configuration and authorization.
• Organisation → Groups: what people can reach: groups, group mappings, roles.
• Organisation → Service accounts: provider account mappings live on the account, not in a separate registry.
• Organisation → Manage → Audit logs: what happened, and what's opt-in. Detailed snapshot.

The rule underneath it: an object lives where the user's mental model puts it, not where the API happens to expose it. Account mappings belong on the account. Group mappings belong on the group.

Solutions for all three tracks are in the section above

Collaboration

Working with engineering (1 eng lead, 2 developers)

The technical design documents were written alongside my flows. I reviewed the API specification, the SSO configuration schema and the token-scope permissions matrix directly, and pushed back at that level. Schema decisions like removing the domain field, or using immutable role UUIDs for scope, are design decisions wearing engineering clothes. Frontend built against a mocked API surface while the backend was in flight, so I reviewed real interactive builds weeks earlier than a sequential process would have allowed.

Working with product & presales (1 PM & presales team)

Presales and support were my highest-signal research channel, because they hold the objection list. In return, the benchmark and entitlement tables I produced went straight into their hands, so "do you support X?" stopped being answered from memory.

Working with documentation (1 Docs lead)

I treated documentation as part of the design and wrote the required/optional attribute tables and per-IdP setup guides. I established a new workflow requiring engineering verification of doc accuracy before publication, alongside in-product documentation links.

Design sign-off

Every screen was walked through with the implementing engineer against the states list (empty, gated, loading, error, partial, destructive-confirm) before it was called done. For identity features the error and gated states are the product, so they got the same scrutiny as the happy path.