Webcuris

Running a scan

AI agent security

A runtime checkpoint for agents acting on your systems: what a tool call is allowed to do, what a session has accumulated, and a tamper-evident record of both.

What this is, and how it differs from AI security

AI security reads your code and tells you what an agent could do. Agent security sits in the running system and decides what it may do, one call at a time.

It is the only part of this platform you wire into your own software. Your agent asks before it acts, and reports what happened.

How to connect an agent

Three endpoints. Your agent calls the first before a tool runs, the second after anything happens, and a human resolves the third when a call needs approval.

  1. Create an API key under Integrations, scoped to agent access.
  2. Before each tool call, POST the session id, tool name and arguments to /api/v1/agent/authorize. It answers allow, require-approval, or deny.
  3. On allow, run the tool. On deny, do not. On require-approval, pause — a person decides in the AI Agents section, and your agent polls GET /api/v1/agent/approvals/{id} until it resolves. An unanswered request expires, and expiry is a refusal.
  4. Report every step to /api/v1/agent/events — tool calls, results, failures, token counts and cost. This is what the session policy reads.
  5. Watch sessions under AI Agents in the sidebar.
The AI agents page listing recorded agent sessions.
POST /api/v1/agent/authorize
Authorization: Bearer <api key>
Content-Type: application/json

{
  "sessionId": "run-8f21",
  "toolName": "db.execute",
  "arguments": { "sql": "DELETE FROM invoices WHERE paid = false" }
}

→ {
  "verdict": "require-approval",
  "reasons": ["tool executes a statement supplied at call time"],
  "blastRadius": { "summary": "…", "inferred": true },
  "credentialsInArguments": [],
  "approval": { "id": "apr_01H…", "expiresAt": "…" },
  "enforcement": "advisory"
}

The verdict is advisory, and says so

Every response carries enforcement: "advisory". This platform does not execute your agent, so it cannot stop a tool call — honouring the verdict is your code's responsibility.

That word is in the response on purpose. Claiming enforcement this platform does not have would be the most dangerous sentence in the product: somebody would rely on a checkpoint that was never in the path.

What this does not do

If your agent ignores a deny, the call still happens. The record will show that it was denied and proceeded anyway, which is worth auditing — but the block itself has to be yours.

Blast radius — should this one call happen

Every authorize request is assessed on its own. The gate looks at what the tool is capable of, not at what it is named: a tool that runs code, a query or a command supplied at call time is treated as unbounded regardless of how harmless the name sounds.

The three verdicts are allow, require-approval and deny. An unrecognised tool does not default to allow — it defaults to needing a person, because a tool the platform has never seen is a tool whose reach is unknown.

Session policy — what only shows up over time

Some failures are invisible in a single call and obvious across a sequence. The session assessment watches the event stream for them.

  • Looping — the same call repeating with no progress.
  • Repeated failure — retrying something that keeps failing, which is usually an agent that has misunderstood the task.
  • Excessive agency — authority quietly accumulated well beyond what the task needed.
  • Action after untrusted content — the agent took an action after ingesting external content, which is the shape of a successful prompt injection.
  • Budget — tool-call count, token, cost and duration limits, per session and across the tenant.

Argument scanning and the hash chain

Tool arguments are scanned in memory for credential-shaped values and then discarded — they are never stored. Findings name the rule and the dotted path, such as headers.Authorization, and never the value. Sending only argumentsHash instead is supported: you keep the arguments entirely, and simply get no credential warning.

Every event is chained to the one before it by hash. Removing or editing an event breaks the chain, so the record of what an agent did is tamper-evident rather than merely stored. The chain starts from an obviously-synthetic genesis value, because a chain starting at all zeroes cannot be told apart from one whose first link was computed over missing data.

Who can see it

Agent telemetry records what an agent was asked to do and what it attempted, which is at least as sensitive as scan data. The account owner sees every session; everyone else sees only their own.