The AI admin plane that never checked for an admin

The challenge

A software vendor had embedded generative-AI features in its platform and wanted them tested the way a customer's own staff would meet them — as an ordinary, non-administrator tenant user holding nothing but a normal business login.

How it unfolded

1. Tested throughout as a plain business user, on a session token that asserted no administrator role.
2. Found the administration interface hid its AI screens client-side only — the services behind them were still reachable, and accepted writes on coarse service-level scopes alone.
3. Wrote the AI pipeline's object-storage credential set — endpoint, region, bucket, access key and secret — then read it back, only partially masked.
4. Wrote the generative-AI prompt configuration, and a separate business-system credential store, with the same ordinary token.
5. Triggered the AI data-ingestion job and operated the full model lifecycle — create a model, train it, delete it.
6. Confirmed it was a gap rather than a design decision: the platform's own identity service enforced an administrator gate and refused the same class of operation for the same user.

Impact

An ordinary business user could decide where the AI pipeline wrote its training and inference data, rewrite the prompts behind generated output, and delete production models — with no administrator role anywhere in the request.

Outcome

Seven findings — one High, two Medium, four Low — delivered as a single root cause rather than a list of endpoint bugs: one administrator-only gate, applied to every mutating operation across the AI administration surface. The platform already had that gate; it had simply not been applied here. Every value written during testing was a deliberately inert marker, itemised for removal in the handover.