Who it’s for
CTOs and Heads of Security at regulated fintech operators who are deploying LLM-backed agents into production — internal copilots, customer-facing assistants, automated dispute / fraud / compliance triage — and need guardrails that the board can sign off on before launch.
Outcome
- Three layers of guardrails — input filter, behaviour cage, output guard — scoped to your specific agent platform
- A board-readable risk story for each agent in production: what it can do, what it can’t, what happens if it tries to
- A red-team plan for each new agent before launch, with a documented pass/fail bar
- A model-risk register mapped to FCA SYSC, EU AI Act, NCSC AI guidance
- A control library that engineering can extend without re-asking us
On pattern across prior engagements: incident triage on the agent path has dropped from hours to single-digit minutes, and policy-violating tool calls have gone to zero in the first 90 days.
Operating model
We embed with the AI platform team for the engagement. We diagram every agent’s tool surface and data access. We design and implement the guardrail controls in your stack — not in a slide deck. We translate the work for the board the same week.
Engagement length & shape
- Initial scope: 6 weeks per agent platform.
- Retainer: monthly thereafter, scoped per new agent.
- Engineering uplift: we work with your team, not over them. Expect a pull request, a runbook, and a board paper at the end of every sprint.
We needed AI guardrails that the board could understand and the engineering team could ship. Salvador Cloud delivered both.
What's NOT in scope
- Building the AI agents themselves
- Model fine-tuning
- Front-end UX for agent-facing surfaces
Anonymised case study
See how this service plays out in practice.
Read the case study →
Frequently asked
We already ship AI agents. Why would we add guardrails now?
Three reasons compound: regulators (FCA SYSC, EU AI Act, ICO) are sharpening expectations on model governance; auditors are starting to ask for a model-risk register and red-team evidence; and the threat surface for production agents (prompt injection, training-data leak, output abuse) is materially different from the surface engineering teams typically defend against. Guardrails turn a board-readable risk story into a control library engineering can extend.How is this different from a generic AI red-team engagement?
Red-team alone gives you a snapshot. We deliver three layers of guardrails (input filter, behaviour cage, output guard) plus a red-team plan that runs every release, plus the model-risk register that maps controls to FCA SYSC / EU AI Act / NCSC AI guidance. The output is a living control system, not a one-off report.Will this slow our development team down?
Pattern across engagements has been the opposite. The control library and the red-team plan land at the platform layer; engineers ship new agents against an existing pass/fail bar rather than re-litigating controls per launch. The first agent through is slower; every agent after is faster.What does the board pack look like?
Per agent in production: what it can do, what it can't do, what happens if it tries to. Plus the latest red-team result and the model risk register summary. Designed to be readable by a CFO or audit committee, not just by engineering leadership.What about the AI agents themselves?
Building the agents, model fine-tuning, and front-end UX for agent-facing surfaces are explicitly out of scope. We work alongside the AI platform team rather than replacing it.
Next step
Ready to scope this engagement?
No proposals, no pitching. We'll diagnose, scope, and price up front.