Trust & Security

// Security · agents are insiders

Agents are insiders. We secure them like one.

An AI agent that can open a pull request or call a cloud API has the reach of a member of staff. So we treat it like one: narrow access, one logged door, and a human sign-off for anything that cannot be undone.

Every control below carries its status. In place means we can show you the evidence named under it. In progress and Planned mean exactly what they say.

Defence in depth

1. 1Scoped identityIn progress

   Every caller of our gateway is a named identity, and the gateway can hold an identity to specific tools and a single code repository. Applying the narrowest such limits to every one of our agents is in progress.

2. 2One logged door: the CLI GatewayIn place

   Our agents reach Google Cloud, GitHub and the business tools they work in through the OpsAgents CLI Gateway. Before a command runs, the gateway records the calling identity and the command in Google Cloud Logging.

   Evidence: per-call log records, shown live in a security review and described in our security questionnaire pack (available on request).

3. 3Destructive commands refusedIn place

   A deny-list stops the highest-impact destructive commands before they reach the provider, whatever the agent was told to do.

   Going further, so the most powerful tools refuse every command that is not on an allow-list of safe command families: Planned

   Evidence: automated tests that prove each refusal, run on every change to the gateway; shown in a security review.

4. 4Credentials stay with the gatewayIn place

   Cloud and SaaS credentials live in Google Secret Manager and are attached by the gateway on its own side. An agent's request names the identity it acts as; it carries no GitHub or Google Cloud key.

   Evidence: described in our security questionnaire pack (available on request) and shown in a security review.

5. 5A human yes for what cannot be undoneIn progress

   Spending money, destructive work on shared or production data, and outreach to new contacts need an explicit human sign-off; agents may not authorise themselves. This is enforced in the agent runtime and in the operating rules every agent loads. Our SOSA™ governor, which holds outbound email, messages and public posts for approval, is being extended to every agent.

6. 6The builder is not the approverIn place

   The agent that builds a change cannot sign off its own work. A guard in our agent runtime refuses a build agent's attempt to push its own work on towards review sign-off, deployment or done; review, QA and release are separate steps.

   Evidence: the guard's refusal records, shown in a security review.

7. 7Every action recordedIn place

   Gateway calls are kept in Cloud Logging for 30 days. Administrative actions on our cloud infrastructure also go to a locked audit log, kept for 400 days, that cannot be shortened or deleted.

   Evidence: the log retention settings, shown in a security review and recorded in our security questionnaire pack.

One door, two requests

Threat, and what contains it

• Prompt injectionHidden instructions in a web page, a file or a tool's output.
  →
  Limit what a misled agent can doNo agent can be made immune to hostile text, so the blast radius is what we control: destructive commands are refused at the gateway, and irreversible or outward actions wait for a human.
  In progress
• A destructive commandSent by mistake, or by an agent that has been steered.
  →
  The gateway deny-listRefused before it reaches the provider. Evidence: the gateway's refusal tests, shown in a security review.
  In place
• Credential theftA key sent out through a chain of tool calls.
  →
  Keys stay with the gatewayStored in Secret Manager and attached on the gateway's side, so agents do not need to hold them. Further hardening is in progress.
  In progress
• Agents collidingTwo agents changing the same thing at once.
  →
  One owner per work itemAn agent claims a work item before it builds, and a runtime guard enforces the hand-off between steps. Evidence: the claim record on every work item, shown in a security review.
  In place
• Tool hijackingA tool or server steering the model toward commands it should not run.
  →
  Deny-list now, allow-list nextToday the deny-list and the human sign-off contain it; default-refuse with an allow-list of safe command families is the planned next step.
  In progress
• Leaking internals in a releaseRepository files or secrets shipped with a website deploy, or introduced in code.
  →
  Checks before anything shipsEvery deploy of this site is checked so repository files cannot be published, and pull requests on our platform get automated static analysis. Evidence: the deploy check and scan results, shown on request.
  In place

We attack ourselves

• Guard tests: every refusal is proven in CI In place
• Static analysis on platform pull requests In place
• Cloud estate self-audit In progress
• Secret-leak checks in CI In progress
• Red-team agent Planned
• Canary data Planned
• Indirect prompt-injection tests Planned
• Tool-hijack tests Planned

Evidence for the two in-place items: CI run history for the gateway's refusal tests and for the static-analysis scan, shown on request.

These are our own internal tests, not a third-party penetration test. Self-audits do find issues; each one is tracked to closure, and we walk security reviewers through the current status (see Security Contact below).