Skip to content

dinpd/AgentPass

BranchesTags

Repository files navigation

AgentPass

Stateful guardrails around AI agent tool calls.

AgentPass is a runtime gate that sits outside the agent loop and checks tool calls before execution.

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

RBAC can say which identity may access a tool. Prompts can suggest how an agent should behave. AgentPass answers the runtime execution question:

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

AgentPass is designed for failures that static access control and prompt rules do not catch:

  • Duplicate side effects, such as repeated refunds, emails, exports, or writes.
  • Runaway tool loops and repeated calls.
  • Token, cost, runtime, and tool-call budget spikes.
  • PII or sensitive data flowing to the wrong destination.
  • Risky actions that need single-action approval.
  • Missing decision logs when something goes wrong.

The gate should run outside the model context and outside agent-editable memory. If the agent can rewrite the rule, grant its own approval, or erase prior state, it is not a real guardrail.

AgentPass is one control model with different entry points depending on where you sit in the agent stack:

  • Agent developers start with the local TypeScript guard to wrap tool calls in an existing agent loop.
  • Enterprise AI and platform teams use manifests, approvals, gateways, policy checks, and audit to govern agents across systems.
  • MCP gateway builders enforce AgentPass before forwarding tools/call.
  • API and SaaS providers publish provider contracts and verify scoped receipts before executing agent-originated actions.
  • Security and risk teams review action policy, PII/data-flow controls, decision events, JIT grants, and kill-switch behavior.

The first package is the local TypeScript guard:

The guard package is published on npm as @dinpd/ai-agent-guard. The repo also includes local demos, starter policies, and the MCP tool-call adapter so developers can validate the policy shape inside an existing agent loop before adding broader gateway or enterprise enforcement.

OAuth can prove access to a server. MCP tool schemas describe inputs. Agent frameworks can decide which tools are visible to a model. AgentPass focuses on the runtime decision immediately before a tool executes.

Why A Stateful Gate

Stateless checks can catch obvious policy violations: blocked tools, unsafe destinations, amount caps, and PII fields.

Many agent failures are stateful:

  • The same refund was already issued.
  • The same email was already sent.
  • The same tool call keeps repeating.
  • The job has crossed a token, cost, runtime, or tool-call budget.
  • An approval was granted for one action, not an open-ended session.
  • A prior denial should stop the job before it keeps trying.

That state has to live in the execution boundary, not in the agent's prompt or scratchpad. The agent can remember what it thinks happened. The gate remembers what actually executed.

For side-effectful tools, AgentPass treats idempotency as part of the runtime boundary. A refund, payment, email, export, or production write should carry an idempotency key or call fingerprint that the gate can remember outside the agent loop.

Approvals should be scoped to one proposed action: tool, resource, payload hash, amount, destination, job, and expiry. If any of those change, the agent needs a new approval.

When every risky action passes through the same gate, audit is not bolted on afterward. The gate log becomes the record of what was proposed, allowed, denied, challenged, and why.

Explainer Video

The_Action_Gate__Securing_AI_Automations-full-github-embed.mp4

AgentPass does not replace IAM, OAuth, MCP gateways, OPA, Cedar, or enterprise security tools. It gives agent runtimes a small policy checkpoint for tool calls, approvals, data movement, circuit breakers, and audit events.

Core Concepts

AgentPass separates three concepts that are often blurred in agent systems:

Skill = workflow package
Tool = executable operation
Flow = data movement boundary
  • Tool: an operation the agent or runtime can call, such as provider.crm.search_customer, stripe.create_refund, or email.send_external. Tool policy answers what operation is being attempted, what access level it has, which resource it affects, and whether approval is required.
  • Skill: a reusable workflow package that may call one or more tools, such as support-refund-workflow. Skill policy becomes relevant when reusable workflows need explicit downstream tool limits.
  • Flow: a source-to-destination data boundary, such as provider_crm -> agent_context or customer_records -> external_email. Flow policy answers where data may move and which destinations are blocked.

The local guard implements tool and flow checks first. Larger deployments can apply the same policy model through manifests, signed receipts, hosted gateways, and provider-side verification.

Entry Points By Audience

  • Platform engineering and SRE teams letting agents inspect systems while gating production deploys, rollbacks, Terraform applies, Kubernetes changes, incident remediation, secrets, and IAM changes.
  • Enterprise AI platform teams reviewing which tools agents may use, under what conditions.
  • Security teams needing approval, audit, and kill-switch evidence for high-risk agent actions.
  • MCP gateway builders enforcing policy before forwarding tools/call.
  • API and SaaS providers turning APIs into MCP tools without giving agents broad authority.
  • API platform and monetization teams preserving entitlements, quotas, metering, and billing controls as APIs become agent-callable tools.
  • Skill authors and platform teams packaging reusable workflows with explicit AgentPass guardrails.

For gateway deployments, AgentPass can run at an enterprise-controlled boundary as the authorization decision service, not necessarily as the network gateway or MCP proxy:

Enterprise Agent -> Enterprise Gateway or App Runtime -> AgentPass Check -> Internal, SaaS, or MCP Tool

If you are an agent developer:

If you are evaluating enterprise governance, gateway enforcement, provider contracts, receipts, or standards alignment:

Quick Start

Try the first developer wedge: add a circuit breaker and approval gate before your agent executes tools.

Install the package:

npm install @dinpd/ai-agent-guard

Run the local demos:

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

Use it in an agent loop:

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;
}

The guard currently demonstrates:

  • Circuit breakers for runaway tool calls, repeated calls, token spend, cost, and runtime.
  • Action controls for approvals, amount caps, and single-use idempotency.
  • PII/data-flow controls for approved destinations, blocked fields, record counts, and model-provider prompts.
  • Audit events for every allow, deny, or challenge decision.

Starter policies:

Enterprise manifest and provider-contract tooling is available when you need a reviewable governance layer beyond the local guard package:

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

AgentPass installs agentpass as the primary CLI and keeps agentid as a compatibility command alias. The Python package, schema filenames, environment variables, and receipt field names still use agentid for compatibility.

Current Status

AgentPass currently includes:

  • Published local TypeScript guard: @dinpd/ai-agent-guard
  • Tool-call and MCP tools/call wrappers
  • Starter policies for spend caps, PII egress, refunds/payments, shell/browser tools, and MCP gateways
  • Runnable demos for refunds, circuit breakers, MCP calls, direct tool gates, and PII flows
  • Cloudflare gateway runtime for approvals, JIT grants, tenant manifests, OIDC checks, and audit events
  • Provider-side Express and FastAPI middleware

Roadmap Focus

Near-term work is focused on production hardening:

  • Idempotency result replay for duplicate side-effect retries
  • Consistent approval evidence across SDK, gateway, UI, and audit events
  • Provider trust gate: signed contracts, drift detection, and execution receipts
  • Clear stateless vs stateful enforcement guidance
  • More integration guides for existing agent stacks

For the full roadmap, see Action Gate Roadmap.

Broader Governance Scope

The same action-gate model can move from an in-process guard to shared boundaries such as app runtimes, MCP gateways, provider MCP servers, and security-controlled policy services.

For enterprise governance, gateway, provider-contract, receipt, and standards documentation, see Enterprise Governance.

Open Source Governance

  • Contributing: development setup, review expectations, and pull request checklist.
  • Governance: project scope, roles, decision making, and security-sensitive change rules.
  • Security Policy: private vulnerability reporting and response process.
  • Code of Conduct: community behavior expectations and enforcement.
  • Support: where to ask questions and what to include.
  • Maintainers: current maintainers and review areas.

License

Apache-2.0

About

Stateful guardrails around AI agent tool calls: policy, job state, approvals, idempotency, PII egress, budgets, and audit before tools execute.

github.com/dinpd/AgentPass

Topics

typescript mcp ai-agents idempotency policy-as-code guardrails llm-agents tool-calling model-context-protocol agent-security runtime-policy pii-egress

Resources

Readme

License

Apache-2.0 license

Code of conduct

Code of conduct

Contributing

Contributing

Security policy

Security policy
Activity

Stars

2 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases 1

AgentID 0.2.0 Latest
Jun 5, 2026

Packages

 
 
 

Contributors

Languages