Security & Assurance/Secure AI Engineering

Close the security gaps before your AI goes live.

Secure AI Engineering turns findings from an AI security assessment, audit or customer security review into controls. Agile Labs deploys and configures AI gateways, guardrails, permissions, logging and agent controls in the organisation’s own environment and tests them against the original findings.

How does Agile Labs address the security issues found in our AI system?

Agile Labs takes the findings from your AI security assessment, audit or review and builds the controls needed to fix them. We implement gateways, guardrails, permissions, agent restrictions and logging directly in your environment.

We then re-run the original tests to verify the findings are closed.

12Protective filters defeated in a single study by adaptive attacks, making the case for designing the architecture around the risk rather than relying on detection alone.Frontier-Lab Adaptive-Attack Study, 2025
150 to 300Overshared sites in a typical enterprise tenant before an AI assistant is switched on.Microsoft Oversharing Research, 2025
Six monthsHow long a permission clean-up can take without a standing routine.Microsoft Oversharing Research, 2025

PAVURE

Findings turned into controls, then verified.

Findings from an Enterprise Readiness Assessment turned into controls in the product: gateway, permissions, agent limits and logging, then re-tested.

  • Assessment
  • Gateway and permissions
  • Agent limits
  • Retest
Read the Pavure story
The Pavure admin console: where requests ran, what was redacted and what was blocked

How we build the controls

We use established security tools and configure them around the organisation’s AI systems, data and access requirements.

Control model access

Route model calls through one gateway to control who can use which models, how much they can spend and what activity is recorded.

Reduce the paths an attack can take

Separate untrusted content, private data and outbound access so one compromised component cannot expose everything the AI can reach.

Limit what agents can do

Give agents and tools only the access their work requires, with human approval before consequential actions.

Record what the controls do

Keep evidence of what was allowed, blocked or changed so the organisation can verify that its AI security controls are working.

The process and timeline

From identified findings to tested controls running in the organisation’s environment.

1PRIORITISE THE FINDINGSFirst

Decide what must be fixed first

Separate what must be addressed before launch from what can follow.

Findings registerFrom an assessment or review
Before launchWhat must hold first
LaterScheduled, not dropped
2GATEWAY AND GUARDRAILS2–4 weeks

Control access to AI models

Route model access through one gateway with identity, logging, budgets and security controls.

IdentityWired to their provider
BudgetsPer team, at the key
GuardrailsInput and output
LoggingEvery call recorded
3PERMISSION CONTAINMENTDays

Remove unnecessary access

Remove access the AI does not need and identify wider permission issues that require separate remediation.

ContainThe worst access, in days
RemediateScoped separately if it runs wide
4AGENT CONTROLS1–3 weeks per workflow

Limit what agents can do

Give agents and tools only the permissions they need, with human approval for consequential actions.

One identity per toolNo shared service account
Human approvalFor consequential actions
Least privilegeOnly what the workflow needs
5VERIFICATION AND HANDOVER1–2 weeks

Prove the controls work

Re-run the original tests, then hand over the configuration, code and operating runbook.

Original tests re-run
Controls confirmed working
Added to CI
Code and runbookHanded to the client

More on securing AI systems

What organisations need to know about turning findings into controls that run.

Why an approved assistant is the bigger exposure

It does not leak. It faithfully returns what the asking person could already open, which after a decade of sharing is usually more than anyone measured. This is why permissions are fixed before it goes live.

Read more

What a model gateway actually buys

One place to apply identity, budgets, rate limits and an approved model list, and one record of what was asked and answered. Without it there is nothing to log, nothing to bill back and nothing to switch off.

Read more

Why a permission cleanup regresses

A typical enterprise tenant carries 150 to 300 overshared sites before any AI is switched on, and the sprawl returns within about six months unless a standing routine keeps it corrected.

Read more

When organisations call us

Call us when

An AI security assessment has produced findings that need to be fixedThe assessment is complete. The organisation now needs engineers to implement the AI security controls and close the findings.A customer security review has found gapsAn enterprise customer or procurement team has identified weaknesses in an AI application, and the controls need to be implemented before the review can close.An AI risk register exists, but nobody is implementing itThe required controls have been documented, but the internal engineering team does not have the capacity or specialist experience to build them.An AI assistant is approaching launchThe application needs a gateway, logging, guardrails, permissions and other controls in place before staff or customers begin using it.An AI agent has too much accessThe agent can reach more data, systems or functions than the workflow requires, and its identity and permissions need to be constrained without breaking the workflow.

Not us when

No assessment has been completed and the organisation does not yet know what needs fixing. The findings come first — the AI Exposure Assessment produces them.The engagement is also not a policy-writing exercise. It ends with controls running in the organisation’s environment, not another document describing what should exist.

Find the security gaps that matter.

Turn AI security findings into controls that actually stop the attack.