AgentAction

Trust infrastructure for autonomous AI agents.

AgentAction is the trust layer between autonomous agents and enterprise systems: it evaluates decisions, enforces policy, authorizes actions, and preserves verifiable evidence across the agent lifecycle. The canonical project site is AgentAction.dev.

AgentAction evaluates decisions, enforces policy, authorizes actions, and preserves verifiable evidence from intent through execution and continuous evaluation.

Intent -> decision assurance -> policy enforcement -> action authorization
       -> execution -> evidence -> continuous evaluation

The action gate is the current enforcement wedge inside that broader trust lifecycle. Versioned agentpass.* protocol identifiers and the legacy agentpass and agentid commands remain supported for compatibility. See Project Positioning for the canonical scope and messaging boundaries.

Try AgentAction

Experience	What it demonstrates
Gateway and refund control	Approval, scoped JIT authority, idempotency, audit, and provider-tool authorization in a support workflow.
DevOps and SRE control	Production-context checks, deployment approval, JIT grants, dry-run dispatch, canary monitoring, and rollback control.
Policy builder	Browser-based manifest authoring with generated YAML, starter OPA policy, and example gateway requests.
Observability console demo	Public, read-only Fleet Overview, finalized Jobs explorer, and deterministic evidence timeline backed exclusively by synthetic fixtures.
Operator console	Cloudflare Access-protected workspace switching, agent integrations, eval routing, Activity, intent-relative outcomes, constraints, confidence, and evidence.

Prefer to start without blocking an existing workflow? Run the passive MCP observer quick start below, inspect the counterfactual policy decisions, and enable enforcement only after the boundary matches your intent. Use the public observability demo to inspect the interface without signing in. The separate operator console remains protected by Cloudflare Access. A new identity can create its first workspace; workspace owners can create additional ones and invite viewers or operators by email. Protected invitation links redeem automatically for the exact signed-in email, and every selected workspace is re-authorized server-side before its data is read.

Quick Start

Hermes Agent: Native Shadow Observer

Install the repository plugin without adding a proxy or changing Hermes tool execution:

hermes plugins install dinpd/AgentAction/integrations/hermes-agentaction --no-enable
hermes plugins enable agentaction

Configure the hosted endpoint, tenant, source, agent, and tool policies once; the plugin then exports privacy-safe lifecycle metadata asynchronously. It is fail open. Hosted setup can explicitly enable bounded agent-declared intent capture; that adds per-turn model context and two self-attestation tools, and the console labels the result as untrusted agent provenance. Add both an explicit intent_id and intent_digest when a run already has an AgentAction contract; otherwise events are correctly labeled unbound rather than having intent inferred from prompts or model output.

See the Hermes onboarding guide for the complete flow. The hosted operator console creates a framework-neutral workspace, then provisions a selected Hermes or generic AgentAction source, displays its token once, shows integration-specific connection steps, and verifies the first event. Each Hermes source still uses a separate write-only token whose hash is stored in that tenant's manifest. Workspace owners can then use Evals to create an immutable eval version and route new Jobs by source, agent, or both without changing the Hermes connection.

Recommended: Observe An MCP Workflow

Run the self-contained observer from a fresh clone:

git clone https://github.com/dinpd/AgentAction.git
cd AgentAction/mcp-gateway-adapter
npm ci
npm run demo:observe

The demo puts the existing reference adapter into passive mode:

MCP client -> customer-run observer adapter -> downstream MCP server
                      |-> local policy + process-local shadow state
                      `-> privacy-safe JSON observation events

Every MCP request and response remains unchanged. The observer records which calls would be allowed, denied, or challenged under enforcement, including stateful findings such as duplicate side effects and tool loops. It does not call hosted authorization, consume approval or JIT authority, filter tool discovery, or attach provider receipts.

The command above is a self-contained onboarding test. To place the adapter in front of representative traffic, set "mode": "observe", configure its downstream.url and tool mappings, then start it with:

npx tsx src/index.ts /path/to/observe-config.json

The current deployment is a customer-run Node HTTP sidecar with process-local shadow state and JSON events written to stdout. Review the observe-mode configuration, transition to enforcement, and limitations before using it with a real workflow. The reference adapter is an onboarding and integration surface, not yet a production-complete MCP gateway.

Alternative: Embed The Guard

For an application that owns the tool execution path, install the local TypeScript guard:

npm install @dinpd/ai-agent-guard

Wrap a consequential tool call:

import { createToolGate } from "@dinpd/ai-agent-guard";

const gate = createToolGate({ policy });

const execution = await gate.run(
  {
    agentId: "support-agent",
    jobId: "case-1042",
    tool: "stripe.refund",
    action: "pay",
    resource: "payment/pi_123",
    amountUsd: 49,
    idempotencyKey: "refund-case-1042-pi_123"
  },
  () => stripe.refunds.create({ payment_intent: "pi_123", amount: 4900 })
);

if (!execution.executed) {
  return execution.decision;
}

Run the embedded-guard repository demos:

git clone https://github.com/dinpd/AgentAction.git
cd AgentAction/packages/guard
npm install
npm run demo:quickstart
npm run demo:mcp
npm run demo:circuit
npm run demo:gate
npm run demo:pii
npm test

The guard package is published as @dinpd/ai-agent-guard. See packages/guard/ for starter policies and more examples.

How It Works

AgentAction connects six claims without collapsing them together: the declared intent, assessment of the decision, policy authorization, provider execution, independent evidence, and continuous outcome evaluation. Authorization is not proof of execution, and execution is not proof that the intended outcome was achieved within constraints.

Action Authorization

Agent proposes tool call -> AgentAction checks policy + state -> allow / deny / challenge

RBAC can say which identity may access a tool. OAuth can prove access to a server. MCP tool schemas describe inputs. Agent frameworks can decide which tools are visible to a model. AgentAction answers the runtime question:

Should this specific tool call, with this payload, in this job state, execute right now?

The gate runs outside model context and agent-editable memory. It keeps the state needed to stop failures that static access control and prompt rules miss:

• Duplicate refunds, payments, emails, exports, deployments, or writes.
• Runaway loops and repeated tool calls.
• Token, cost, runtime, and tool-call budget spikes.
• PII or sensitive data moving to the wrong destination.
• Risky actions without action-scoped approval.
• Replays or payload changes after authority was granted.

Approvals bind to the proposed tool, resource, payload, amount, destination, job, and expiry. Side-effectful actions bind an idempotency key or call fingerprint to the recorded provider result. The gate therefore remembers what actually executed rather than relying on what the agent thinks happened.

AgentAction separates three concepts that agent systems often blur:

Skill = workflow package
Tool = executable operation
Flow = data movement boundary

The local guard applies tool and flow checks in-process. Larger deployments use the same model through manifests, approvals, hosted gateways, signed receipts, provider-side verification, and durable evidence.

At enterprise scale, every consequential action crosses an enterprise-controlled gateway before reaching internal, SaaS, cloud, or provider-hosted tools. AgentAction acts as the decision service; the gateway remains the policy enforcement point, and providers can independently verify scoped authorization receipts.

AgentAction also fits into broader task-scoped security architectures such as Cloudflare's Agent Access Model (AAM). It implements the action-control and evidence layers while integrating with external identity brokers and network enforcement rather than replacing them.

Choose Your Path

You are building	Start here
An existing MCP workflow or gateway	Start with the recommended passive observer quick start, then use the mcp-gateway-adapter/ integration guide
An agent or application	packages/guard/ and the local examples
An enterprise AI platform	Enterprise governance and authorization in practice
A SaaS, API, or MCP provider	Provider MCP authorization, Express middleware, or FastAPI helpers
A security or risk program	Enterprise topology, receipt profiles, and standards alignment
An observability or assurance implementation	Intent assurance, the operator console, and community proposals

For the enterprise CLI and manifest workflow:

git clone https://github.com/dinpd/AgentAction.git
cd AgentAction
python -m pip install -e ".[dev]"
agentaction validate examples/provider-mcp-support-agent.yaml
agentaction risk-score examples/provider-mcp-support-agent.yaml
agentaction generate-policy examples/provider-mcp-support-agent.yaml --target opa

The Python distribution is agentaction-dev. agentaction is the primary CLI. agentpass and agentid remain compatibility aliases, and versioned schema, environment-variable, and receipt identifiers retain their existing names.

Platform Control Surfaces

AgentAction exposes three connected control surfaces:

1. Agent Evaluation: define versioned intent profiles, exercise synthetic scenarios, and compare profile-scoped assurance signals before wider deployment.
2. Decision Assurance: assess the declared basis for a consequential choice, including policy factors, alternatives, assumptions, uncertainty, and supporting evidence—without inspecting hidden chain-of-thought.
3. Action Authorization: gate the exact action against policy and prior state, then issue action-bound authority that providers can independently verify.

Provider verification, execution receipts, verified observations, immutable assessments, and outcome evaluation connect the three surfaces across the trust lifecycle. Framework wrappers, gateway adapters, and conformance suites are delivery and interoperability mechanisms, not separate product surfaces.

Current Capabilities

• Versioned intent profiles, synthetic scenarios, immutable assessments, and profile-scoped quality rollups provide the Agent Evaluation foundation.
• Normalized decision evidence captures policy factors, alternatives, assumptions, uncertainty, and supporting evidence without recording private chain-of-thought.
• Local TypeScript action authorization with circuit breakers, budgets, approvals, idempotency, PII/data-flow controls, and decision audit events.
• Passive observe and fail-closed enforce modes for MCP tools/call through the reference MCP gateway adapter.
• Cloudflare gateway runtime with tenant manifests, OIDC checks, approval queues, scoped JIT grants, audit timelines, and provider-result replay.
• Provider authorization receipts signed as JWS with a public JWKS endpoint.
• Express and FastAPI provider-side verification middleware.
• Versioned intent contracts, execution evidence, verified outcome observations, immutable snapshots, final evaluations, and quality rollups.
• Public synthetic-data observability demo plus an Access-protected operator console for fleet-level outcome, constraint, confidence, execution-discipline, and data-quality review.
• DevOps/SRE and OpenClaw solution packs for concrete integration paths.

See Current implementation status for planned and adopter-facing work.

Architecture And Documentation

• Enterprise deployment and governance
• Enterprise-managed MCP authorization sequence
• Action-gate roadmap
• Intent assurance
• Decision-basis evidence
• Provider contracts and authorization
• Agentic identity standards crosswalk
• Interoperability positioning
• Explainer video

Community Specifications And Roadmap

AgentAction publishes experimental, vendor-neutral drafts for Agent Action Boundary Evidence and Agent Outcome Observability and Assurance Metrics. They are discussion documents, not adopted standards; AgentAction is a non-normative reference implementation.

Implementation work and identified gaps are tracked in the public Intent Observability & Assurance project. The Action Gate Roadmap tracks product layers and adopter-facing demonstrations.

Open Source Governance

• Contributing
• Governance
• Security policy
• Code of Conduct
• Support
• Maintainers

License

Apache-2.0