Agent Action Ledger

Your agent can only do what the Agent Action Ledger allows.

Agent Action Ledger stands between AI agents and the systems that can cause real-world consequences. Instead of letting agents touch SMTP servers, webhooks, internal APIs, or other sensitive integrations directly, it routes every action through a controlled execution layer where identity is verified, permissions are enforced, and the requested capability is checked before anything happens. That changes the security model in a meaningful way: agents do not operate on trust, intention, or best behavior. They operate inside a boundary you define. Every request is authenticated, evaluated against server-side policy, and executed only through approved pathways, giving operators a reliable way to control what agents are allowed to do before risk becomes damage.

Just as important, Agent Action Ledger makes accountability structural rather than aspirational. Each action is recorded in a tamper-evident chain that links request, authorization context, execution result, and ownership into a single defensible record. That means teams are not left stitching together traces from logs, third-party providers, and agent frameworks after the fact, hoping the story holds up under scrutiny. Sound familiar? They can see who acted, what was requested, whether it was allowed, what happened next, and whether the record has remained intact since it was written. For environments where legal review, compliance pressure, operational risk, or customer trust actually matter, that is the difference between “we think this is what happened” and “here is the verified chain of events.”

The Problem

Agent actions are real-world risk, but most stacks treat them like app logs.

AI agents are now sending email, posting content, calling internal APIs, and triggering financial or operational workflows. Most teams rely on conventional logs and post-hoc reconstruction to answer basic audit questions:

• Which agent did this?
• Who authorized this agent to do it?
• What exactly was requested?
• Was the action blocked, rejected, or executed?
• Has this record been modified since it was written?

In many environments, those answers are fragmented across orchestrator traces, app logs, and provider logs. That is not enforcement. That is hope.

Agent Action Ledger closes this gap by making the control path and the evidence path the same path.

How It Works

Proxy-first enforcement, not advisory logging.

Agent Action Ledger sits inline between agents and capabilities:

1. Agent calls AAL capability endpoint.
2. AAL authenticates the agent key.
3. AAL verifies capability grant and rate policy.
4. AAL writes the intent and cryptographic linkage.
5. AAL executes through server-held credentials.
6. AAL writes outcome and returns response.

If the capability is not granted, execution is rejected and recorded.

If the agent is suspended, execution is rejected and recorded.

If auth fails, the attempt is recorded in security events.

The agent never receives direct integration credentials, so it cannot bypass the gateway by design.

The Proof Model

Accountability is derived, not asserted.

In many systems, an agent can submit a free-text requester field. That is not auditable authorization.

AAL derives authorization from registration ownership:

• Admin registers the agent and owner.
• Agent proves identity via key verification.
• Capability access is enforced against grants.
• Ledger records owner as the accountable authorizer.

Agent agt_abc123 authenticated successfully, requested send_email, was granted send_email by policy, action recorded at sequence N, params hash logged, result persisted, chain verified.

No unverifiable requester string. No retroactive interpretation.

Security Positioning

Built for teams that expect legal and compliance review.

Agent Action Ledger includes:

• Bcrypt-based agent key verification
• Constant-time key comparisons on direct key paths
• SQL parameterization across storage layer
• SMTP header-injection guards
• URL whitelist enforcement for configured HTTP GET capabilities
• Hash chaining with canonical JSON serialization
• Segment checkpoints for efficient verification
• Security events for auth failures and lifecycle operations
• TLS requirements in licensed operation (daemon and MCP)

This is not blockchain marketing. This is practical, inspectable tamper-evidence with predictable operational behavior.

MCP Story

Native MCP tools without surrendering control.

AAL ships with an MCP server that exposes configured capabilities as tools.

That means a Claude-compatible agent can call your approved capabilities through MCP while enforcement still happens in AAL:

• MCP tool request arrives
• MCP authenticates to daemon with service credential
• Daemon applies same policy and ledgering flow as any other client
• Action result is returned with chain-linked record

MCP is the integration surface. AAL is the control plane.

Operator Experience

One binary. Local storage. Immediate visibility.

• SQLite-backed ledger with queryable action history
• Terminal UI with chain status and security-events panel
• Live filters by agent, capability, status, and date range
• Startup integrity verification before serving requests
• Background verification on interval

No sidecars. No mandatory external control plane. No telemetry relay required.

Licensing / Procurement

Per-instance annual licensing. Enterprise-ready procurement.

Agent Action Ledger is licensed per instance, per year.

• Standard pricing: $999/year per instance
• Multi-instance and enterprise terms available
• Air-gapped and constrained-environment support available
• PO and net terms supported

M Media Software Lab is a registered US vendor (DUNS and EIN on file).