Skip to content
A steel mesh cage door locked with a heavy padlock, server racks glowing faintly behind it.

Service 07 · AI Security

Give agents access, keep your controls

Give an agent write access and you open routes your controls were not built for.

Book a readiness review
  • Your programme assumes a human who can be revoked
  • An agent has a credential, tools, and a context window
  • Most routes close at the point where the agent acts
  • A policy document leaves them open

Example record

What the agent tried, and what happened

So you see each call your agent made, and what stopped it. A refusal is kept with its reason.

The rules behind each line are configuration in your repository.

session log · tool callsSample log

  • Read src/payments/retry.ts

    inside project scope

    Allowed

  • Read .env.production

    secret path

    Refused

  • git push --force origin main

    protected branch

    Refused

  • Call an external payments API

    needs approval first

    Asked

  • Run the test suite

    sandboxed, scoped credentials

    Allowed
A thick steel hasp and padlock closed on an industrial cabinet door.

Where it closes

Closed where the call is made

A denial that only writes a log line lets the call through. Your refusals happen at the tool boundary.

Capabilities

The surface your existing controls miss

Four routes an agent opens that a programme built for people does not watch.

01Tool scope is the permission boundaryAn agent with shell access has whatever the shell has. So you ask what each tool can do, and check that its refusals are enforced.
02What the agent reads can instruct itA dependency's README, an issue comment, a page fetched during research. In the context window it competes with your instructions, and teams rarely count research as input.
03Secrets leak sidewaysAn agent rarely prints a credential. It reads a file that holds one, and the contents ride in a context window re-sent each turn, and possibly logged.
04The supply chain now includes a modelA model version, a provider’s terms, a region, and what a hosted endpoint retains. They belong in your package inventory, and they are rarely there.

What the agent reads is the widest way in

A README, an issue comment or a page fetched mid-task can carry an instruction. So we put hostile text in those places in a test, before production, and show you what your agent did with it.

A figure obscured behind a projected wall of shifting digits.
  1. A

    Any text read mid-task can carry an instruction

  2. B

    We trace which tools that text can reach

  3. C

    We put hostile content where the agent reads

  4. D

    Findings land as committed checks

How we test your pipeline

We reach your pipeline the way an attacker would, then close what opens.

  • Each tool reviewed for what it can reach

  • Denials that only log are found here

  • Credential paths traced: what opens them, what logs retained

  • Model, version, terms and region checked against your contract

  • Each finding closes as a committed check

Model

What we fix, and what you decide

What we fix

  1. F1Denials enforced at the tool boundary, then retried
  2. F2Hostile content is tested in each path the agent reads
  3. F3Credential paths are refused before they open
  4. F4Model, version, provider terms and hosting region are inventoried and pinned
  5. F5Findings land as committed checks

What you decide

  1. C1Which repositories and environments are in scope
  2. C2Who fixes the findings, our team or yours
  3. C3Provider and region, against your contract

Related

Where to go next

Next step

List the tools your agent can call.

We trace what each one reaches. What you get is a decision on each route in, closed by a committed check or left open on your sign-off.

Book a readiness review →