AgentProofKit

Agents, under control.

Audit, secure & ship with confidence.

The open-source kit maps what each agent can reach, attacks its tools and permissions and writes the alerts that watch it after launch. When you need an independent verdict, we sign the go/no-go.

  • Open source, Apache-2.0
  • Read-only, runs on your machine
  • No telemetry
$ agentproofkit inspect ./support-agentSample output
IdentityRuns as svc-agent, member of sudoReview
SecretsMCP server inherits 2 tokens it never usesReview
Tools4 tools pinned to sha256 1933bf…, no driftAllow
Data reach3 sources, 1 outside the agent's scopeReview
Alerting6 rules written to ./rules for Splunk and SentinelReady

support-agent, 2 MCP servers

3 findings to fix before go-live.

  • Move the agent off the sudo account first.
  • Fixes written to fixes.md
  • Alert rules ready for your SIEM

Agents ship faster than anyone can secure them.

Security teams are asked to approve agents they have no method to review. So they block the launch, or they sign off blind.

~50%

of agentic AI projects are still stuck in pilot or proof of concept, held back by governance and validation.

Dynatrace, The Pulse of Agentic AI 2026, 919 leaders
14

findings on a test agent that had just blocked a poisoned tool, 8 of them flagged for review before go-live.

AgentProofKit lab review, October 2026
1

changed sentence in an MCP tool description was enough to make a test agent open a file nobody asked for.

AgentProofKit lab, October 2026

What keeps security teams up, and what we do about it.

The fearWhat AgentProofKit does

It acts with someone else's identity.

Agents often run on the builder's account or a shared service account with far more rights than the task needs.

We map the identity it really uses.

Account, groups, tokens and scopes, with the least-privilege fix. inventory.json

Its tools can change after you approved them.

An MCP server can rewrite a tool's description at runtime, and the model follows it.

We pin every tool and stop drift.

Each description is fingerprinted; a change blocks the agent before the model call. tool-baseline.json

A document can give it orders.

Instructions hidden in an email, a ticket or a file reach the model as if they were yours.

We attack it with those documents first.

Indirect prompt injection scenarios on the agent's real tools, each finding with its proof. findings.md

It can reach data nobody mapped.

One connector too many and the agent reads, or sends, what it was never meant to see.

We draw its data perimeter.

Every source it can read or write, flagged when it falls outside scope. risk-map.json

Nobody watches it after launch.

The review is a snapshot; the agent, its tools and its rights keep changing.

We hand you the alerts.

Detection rules for your SIEM that fire when the agent drifts. rules/

This is what an agent under control looks like.

Every call goes through a known identity, to pinned tools, inside a mapped perimeter. When something changes, the call stops and your SIEM hears about it.

  • Calls to reviewed tools pass, logged.
  • A tool whose description changed is blocked before the model sees it.
  • The block raises an alert in your SIEM.
Requestfrom a userguard: identity, tool pins, scopeAgentsvc-support, scopedCRMpinned, readTicketspinned, readDocspinned, readbilling-toolsdescription changedBlocked before the modelhash 602cde ≠ baseline 1933bfSIEM alerttool_description_drift
Model calls on the blocked session: 0Blocked in 4 ms, lab run

One agent, secured end to end.

From the first risk map to the alerts that keep watching it after launch. Each step leaves a file you can read, diff and keep.

Risk

What the agent can do, as whom, on which data and tools.

risk-map.json

Audit

Identity, permissions, MCP tools with a fingerprint of each description, data reach.

inventory.json

Pentest

Poisoned tools, indirect prompt injection, over-broad permissions, exfiltration.

findings.md

Harden

The configuration fix for every finding, highest risk first.

fixes.md

Monitor

Alerting rules for your SIEM, ready to deploy after launch.

rules/

It keeps watching after launch.

The kit writes detection rules for the agent it inspected. Deploy them in your SIEM and get an alert when something changes under the agent.

  • A tool description changed since review
  • The guard was disabled by configuration
  • An unknown tool appears on an MCP server
  • A tool call falls outside the agent's normal set
  • A data source is read outside scope
  • The agent's identity is used by another process
rules/splunk/tool_description_drift.splSplunk
index=agents sourcetype=agent:trace kind="mcp.tools_list"
| spath path=tools{} output=tool
| mvexpand tool
| spath input=tool
| eventstats earliest(description_sha256) as baseline by name
| where description_sha256 != baseline
| table _time agent name baseline description_sha256
Fires when a tool's description no longer matches the one you reviewed.

The kit is free. The proof is signed.

Start with the open-source kit. When you need an independent verdict for your CISO or your auditor, we review the agent ourselves.

Open-source kit

Free, Apache-2.0

  • Inventory of identity, permissions, tools and data reach
  • Tool description pinning and drift detection
  • Raw findings in JSON and Markdown
  • Alerting rules for Splunk and Sentinel
Get early access

Signed review

Fixed price, quoted per agent

  • Attacks on the agent's real configuration
  • Every finding with its proof level and verdict
  • Configuration fixes and an evidence pack
  • A signed go/no-go for your go-live board
Request a review

Be first to run the kit.

The kit is in development. Leave your work email and we will send the first release and its documentation.