Developer path

Connect one agent without learning the whole platform.

The product owner starts the project and rules. The developer adds one security call before the agent reaches a model or tool boundary. Everything else can follow when needed.

Before code

Separate the human and developer jobs.

Product owner or security admin

Decide what should be allowed

  • Name the agent and environment.
  • Choose safe tools and sensitive actions.
  • Approve exact high-impact actions.
  • Review denied events and fixes.
Developer

Put the check at the real boundary

  • Create a scoped project key.
  • Send a unique request ID.
  • Submit the proposed content or tool call.
  • Execute only when the decision allows it.
Implementation

Six steps, in the order they matter.

  1. 1

    Create the project

    Use development first. The control plane can run a fictional protection test before any integration.

    Open the project →
  2. 2

    Create a scoped connection key

    The key is shown once, stored as a hash and can be expired or revoked immediately.

    Open Connect →
  3. 3

    Add the Guard request

    Call the decision endpoint before the agent performs the action. Do not execute on deny or error in fail-closed mode.

    View the request →
  4. 4

    Require exact approval for material actions

    Bind approval to the project, environment, tool, arguments, target, value and expiry.

    View approval flow →
  5. 5

    Inspect the real system

    Run the authorised local inspector to compare declared controls with code and configuration.

    Open evidence →
  6. 6

    Retest before the deployment decision

    Attach remediation evidence and rerun the specific failed control or attack case.

    Open Fix and retest →
Step 3 · Guard request

Check before execution

curl -sS https://agentrisklayer.com/v1/guard \
  -H "Authorization: Bearer arl_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "agent-step-123",
    "tool_call": {
      "name": "crm.read",
      "arguments": {"customer_id": "cust_123"},
      "context": {"environment": "development"}
    }
  }'

Only continue to the real tool when the authenticated response is allow. Use a new unpredictable request ID for each new action.

Step 4 · Exact approval

Approve the operation, not a vague intention

An owner or project admin issues approval inside the authenticated control plane. The resulting token is short-lived and bound to the canonical action digest. A changed target, amount, environment or tool is denied; a consumed token cannot authorise a second action.

Resolve material values before approval. Guard can bind only what it receives. If a downstream service discovers or changes an amount, target or other material value after the Guard decision, use an authoritative prepare or quote step and execute only the same unexpired committed value. Per-action approval is not a cumulative spend or usage limit; enforce aggregate ceilings atomically in the authoritative system.

Step 5 · Local inspection

Create technical evidence without uploading source code

curl -fsSLO https://agentrisklayer.com/downloads/agent-risk-inspector.mjs
node agent-risk-inspector.mjs scan . --authorised \
  --environment test \
  --out agentrisk-inspection.json \
  --sarif agentrisk-results.sarif \
  --fail-on high

The local Inspector produces redacted JSON evidence and SARIF for code-scanning workflows. Source contents and matched secret values are excluded from the evidence bundle.

Evidence and privacy

Know what crosses each boundary.

Hosted Guard

Submitted content is evaluated transiently. Persisted evidence contains digests, rule identifiers and bounded metadata.

Local inspection

Repository evidence is generated on the customer machine. Source contents and secret values are excluded from the uploaded bundle.

Controlled red team

Use authorised non-production targets and written Rules of Engagement. Raw attack transcripts are excluded from hosted evidence.