Security for the AI agents you run

Every AI agent that can read a mailbox, query a database or call an API is a new door into the company, and it opens for whoever writes the right sentence in front of it. Most companies already have more of these doors than they know of: the assistant somebody connected to their mailbox, the chat tool with a key to the shared drive, the agent a vendor switched on. We map those doors, lock each to what its agent needs, record what passes through them, and test that the locks hold.

Mapped: every agent and what it can reach

You cannot protect a door you have not counted. We list every agent in use — the ones IT approved and the ones staff connected on their own — with the credentials it holds, the tools it can call and the data those reach. The map is a document kept with your configuration and updated when an agent is added, not a slide made once for a meeting, and it is the first thing an auditor, a large customer or an insurer will ask to see.

Locked: each agent on least privilege

An agent gets its own identity and the smallest privilege its job needs: roles rather than shared accounts (RBAC), read-only by default, writes only through narrow tools with limits on how often and how much. Secrets are split per agent and per host, never pasted into a prompt, and rotated without a code change. Text an agent reads — an email, a web page, a document — is treated as data, never as instructions, so a message that says “ignore your rules” grants nothing. Controls fail closed: when a check cannot run, the action is refused.

Recorded: what it did, and for whom

Every tool call is logged with the person it acted for, what it was asked, what it touched and what came back, and the log is kept where the agent itself cannot change it. Alerts fire on the unusual — a burst of reads, a tool used at three in the morning, access to data the agent has never needed. When something does go wrong, the record is what turns an incident into a timeline rather than a guess.