Sarja

AI Governance & Security

AI you can put in front of staff, customers and sensitive data.

We build the controls around your AI systems — who can use them, what they can see, which models they call and what they're allowed to do — enforced by the system, not requested in a prompt.

Talk to SarjaWhat's included

Why organisations commission it

  • Limits that hold, whatever a user types
  • Clear visibility of usage, behaviour and cost
  • The groundwork to deploy AI where the stakes are high

A system prompt is an instruction, not a boundary.

A model told to stay on topic can be talked out of it. And even a well-behaved assistant still runs on logins, APIs and databases that need ordinary, rigorous security.

We implement limits in the gateway, identity, integrations and infrastructure around the model — where a user can't argue past them — and keep a record of what happened.

What we deliver.

Put enforceable controls around every AI system you run.

  • AI gateway with central policy enforcement
  • Role-based access and SSO integration
  • Model and provider allow and deny rules
  • Personal information and data-loss controls
  • Approval workflows for agent actions
  • Audit logging and usage dashboards
  • Token budgets, quotas and spending limits
  • AI usage policy and change control

What happens without hard enforcement.

Two documented public incidents with different causes and the same lesson: a well-behaved chatbot is not the same thing as a secured system.

Public incident · December 2023

Chevrolet of Watsonville

A customer-facing dealership chatbot, built on a general-purpose language model, was manipulated well outside its intended role through prompt injection.

What happened

A California Chevrolet dealership deployed a ChatGPT-based chatbot on its website to answer customer questions. A user gave the bot instructions designed to override its role — telling it to agree with everything he said and to close every message with a line claiming the offer was legally binding.

The bot complied, appearing to agree to sell a new Tahoe for one dollar. The exchange went viral. Other users pushed the same bot into unrelated territory — recommending competitors' vehicles, writing code, answering questions with nothing to do with car sales — showing it was a thin wrapper around a general-purpose model rather than a system with any real boundary around it.

The dealership did not sell a vehicle for one dollar. What the incident showed was structural: the model underneath the chatbot remained a fully general-purpose system. Nothing enforced what it was actually allowed to discuss, promise or commit to on the dealership's behalf — the "you are a dealership assistant" framing was one instruction among many, and a user's contradicting instructions could simply outweigh it.

The lesson

A system prompt is an instruction, not a boundary. Scope has to be enforced outside the model — in what it's allowed to see, say and commit to — not requested inside it.

Public incident · June 2025

McDonald's / Paradox McHire

A recruiting platform used across the majority of McDonald's franchises exposed applicant data through weak credentials and an access-control flaw — not a prompt-injection issue.

What happened

McHire is a recruiting platform built by Paradox.ai and used by the large majority of McDonald's franchise locations, screening applicants through a chatbot called Olivia. Security researchers Ian Carroll and Sam Curry found that a test account on the platform's admin panel was protected by the username and password "123456" and "123456."

That default credential gave the researchers access to a live administration interface. From there, they identified an insecure direct object reference (IDOR): applicant records could be enumerated sequentially just by changing an ID in a request, with no check that the requester was authorised to see that specific applicant's data.

This is not a story about tricking a model into saying something it shouldn't. It's a story about identity, authentication and permissions — the infrastructure around the AI system, not the AI system's conversational behaviour. Paradox.ai disabled the exposed test account and patched the endpoint within hours of disclosure, and stated that only the two researchers who reported the issue had accessed candidate records.

The lesson

AI products still run on ordinary infrastructure — logins, APIs, permissions, identity. A conversational layer that behaves well is no substitute for access controls that actually hold.

How it works.

  1. Step 1

    Inventory

    The AI systems, users, data and providers in use or planned.

  2. Step 2

    Set boundaries

    Access, data, model and action policy for each system.

  3. Step 3

    Enforce

    Controls in gateways, identity and infrastructure — not prompts.

  4. Step 4

    Monitor

    Audit usage and behaviour, and revise as things change.

Usually delivered alongside

Let's find the first AI system worth building.

Tell us about the workflow, system or data involved. We'll come back with a straight view of what's possible, what it would take, and where to start.

Talk to SarjaBrowse services