AgentAction
Project transition

AgentAction is the public brand for AgentPass. Existing package names, schemas, commands, and repository links remain compatible while the project migrates.

Open-source action control for AI agents

Control the action.Prove what happened.

AgentAction is an action-authorization and execution-assurance layer outside the agent loop. It decides whether a specific tool call may execute now—and preserves independently verifiable evidence of what was authorized and executed.

Try the guard See the boundary
  • Apache-2.0
  • Model-agnostic
  • MCP-aware
  • Fail-closed controls
action.requestboundary active
toolstripe.refund
resourcepayment/pi_123
amount$1,200.00
jobcase-1042
DENY

Amount exceeds the $100 policy maximum.

decision_iddec_01JAA4…A91C
The model proposes. The boundary decides.

01 / The gap

Identity tells you who. AgentAction decides whether this action should run.

OAuth can establish access to a server. IAM can assign roles and entitlements. Tool schemas can describe available operations. None of those alone answers whether this exact payload, in this job state, with this approval and prior history, may execute right now.

02 / The action boundary

One controlled lifecycle, end to end.

Authorization is not the same as execution, and an allow decision is not proof of a successful outcome. AgentAction links the lifecycle without collapsing those claims together.

  1. 01

    Propose

    The agent proposes one concrete tool call and payload.

  2. 02

    Establish context

    A trusted runtime supplies identity, job, state, and approval facts.

  3. 03

    Authorize

    Policy and durable state return allow, deny, or challenge.

  4. 04

    Execute

    The provider verifies the exact-action authority and applies its own rules.

  5. 05

    Assure

    Receipts and observations preserve what happened and how it was assessed.

Trusted action boundary
proposed → authorized → executed → observed → assessed

03 / Trust model

The agent never becomes its own authority.

Security facts come from authenticated systems and durable state, not from conversation text or agent-editable memory.

SignalPostureBoundary rule
Agent outputUntrusted proposalNever treated as authority by itself
Identity and job contextVerified inputDerived by the trusted runtime or gateway
Policy and prior stateEnforcement inputHeld outside prompts and agent-editable memory
Authorization receiptPortable evidenceBound to the exact action, audience, and decision
Execution and outcomeIndependent evidenceKept distinct from the authorization decision

04 / Proof, not promises

What exists—and what comes next.

AgentAction labels experimental work and roadmap items plainly. The public repository, runnable examples, fixtures, and tests are the source of truth.

Available now

Runtime action control

Local and hosted checks for exact tool calls, approvals, amount caps, budgets, circuit breakers, sensitive-data movement, idempotency, and replay protection.

Available now

Provider-verifiable authority

Signed, action-bound authorization receipts, public verification keys, provider middleware, contracts, fixtures, and negative conformance cases.

Available now

Execution assurance

Linked execution receipts, immutable evidence snapshots, verified observations, versioned intent contracts, and outcome assessments.

Roadmap

Causal observability

Richer OpenTelemetry correlation across runs, boundary decisions, tool calls, retries, provider execution, observations, and assessment evidence.

Roadmap

Monotonic task authority

Task-scoped capability state that can remove incompatible authority after protected events without silently expanding what an agent may do.

External proof target

Independent interoperability

Two independent providers passing the same public action-authorization cases without project-specific runtime coordination.

05 / Developer entry point

Put policy around the side effect.

Start with the published TypeScript guard. The existing AgentPass package name remains during the brand migration.

Open the guard package
agent-loop.tsTypeScript
import { createToolGate } from
  "@dinpd/ai-agent-guard";

const gate = createToolGate({ policy });

const result = await gate.run({
  agentId: "support-agent",
  jobId: "case-1042",
  tool: "stripe.refund",
  resource: "payment/pi_123",
  amountUsd: 49,
  idempotencyKey: "refund-1042-pi_123"
}, executeRefund);

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

06 / One boundary, four entry points

Meet the project where you build.

01

Agent developers

Wrap consequential tool calls with a small authorization boundary inside an existing agent loop.

02

Platform and gateway teams

Apply consistent action policy before forwarding MCP tools/call or other privileged operations.

03

API and SaaS providers

Verify action-specific enterprise authority before mutation, then apply provider business authorization.

04

Security and assurance teams

Connect proposals, approvals, decisions, execution, observations, and assessments without trusting the model as the record of truth.

07 / Open standards posture

Build interoperability before vocabulary.

AgentAction reuses established identity, policy, transport, signing, and provenance work where it fits. The project contributes mappings, negative fixtures, reference verifiers, conformance cases, and narrowly scoped experimental profiles. Its community drafts are not adopted standards or external certifications.

Community RFCsContributing guideProject governanceSecurity policy

The action is the unit of control.

Help define a portable boundary for trusted agent action.

Explore AgentAction on GitHub Join the discussion