Local pre-execution authorization for financially consequential AI-agent tool calls.

AEGIS Core sits between an agent's reasoning/runtime layer and high-risk tools such as payments, trades, paid APIs, and other external side effects.

Within a single process, AEGIS makes budget and idempotency decisions before execution is permitted. In the tested same-ID case, 100 concurrent retries produced 1 execution grant, 99 cached replays, and 1 simulated external execution.

An autonomous agent does not need to be malicious to create financial damage.

Retries, asynchronous execution, runaway loops, or multiple workers can cause several individually valid tool calls to compete for the same remaining budget or repeat the same logical action.

For financially consequential tools, the critical question is:

What happens if an agent retries the same expensive action concurrently before the previous execution has fully resolved?

AEGIS Core places a local authorization boundary before that external side effect.

AEGIS Core is a local Python policy gate designed to make authorization decisions before financially consequential tool execution.

It focuses on deterministic local state control rather than replacing the agent framework itself.

• Budget Enforcement: Block execution when the remaining authorized budget is insufficient.
• Idempotency Control: Prevent duplicate logical tool executions from being authorized twice.
• Concurrency Control: Serialize competing local authorization decisions around shared economic state.
• Framework Agnostic: Can sit in front of LangChain, AutoGen, CrewAI, MCP integrations, or raw Python tools.
• Local Enforcement: The current implementation does not require Redis, Kafka, or a remote policy service for its local mode.
• Fail-Closed Security: Invalid authorization/signature conditions are rejected rather than silently allowed.

Current scope: AEGIS Core's tested atomicity guarantees are local and single-process. Distributed multi-process or multi-node coordination is not claimed.

In a reproducible local stress test, 1,000 authorization requests were submitted through 100 workers while competing for a budget sufficient for only one operation:

• ✅ 1,000 authorization requests
• ✅ 100 workers
• ✅ 1 request allowed
• ✅ 999 requests denied
• ✅ 0 overspend
• ✅ Final balance remained consistent
• ✅ Financial-loss regression matrix: 12/12 PASS

AEGIS also includes reproducible tests for:

• ✅ Idempotency conflicts
• ✅ Tool-call cryptographic binding
• ✅ Signature failure rollback
• ✅ Concurrent limited-budget settlement
• ✅ Atomic rollback
• ✅ Exact replay handling

Current local benchmarks include:

• Decision primitive: ~0.5 µs median
• Idempotency cache hit: ~2.4 µs median
• Full signed authorization: ~46.7 µs median
• SQLite in-memory L3 settlement: ~147.7 µs median

These measurements describe the tested local execution paths only.

They do not represent HTTP/network round trips, distributed coordination, Stripe settlement, blockchain confirmation, or other external infrastructure latency.

AEGIS Core 3.4.0 has received a public external source review and benchmark in kube-coder issue #573.

Externally reported local measurements:

The evaluator did not recommend adopting AEGIS as the dependency for kube-coder Phase 4 because its deployment needs differed from AEGIS 3.4.0's current process-local model. That limitation is part of the public record.

The same evaluation carried six AEGIS design patterns into kube-coder's Phase 4 notes: durable decision receipts, idempotency conflict detection, integer money units, commit ordering, fail-closed behavior, and attenuated policy decisions.

What this proves: external source inspection, external benchmark, external fit assessment, and documented design influence.

What it does not prove: kube-coder adoption, integration, production validation, distributed atomicity, or endorsement.

Full evidence: LortuArte/aegis-sdk — External kube-coder evaluation

Primary sources:

• External evaluation and benchmark
• Phase 4 design notes
• Author correction / scope clarification

A retry/disconnect failure mode reported by Iraitz / LortuArte was credited in the merged upstream PayMCP PR #52, titled “Return the paid result on retry instead of running the tool twice.”

The upstream PR documents a paid-tool failure mode where:

paid tool executes
        ↓
client disconnects before receiving the result
        ↓
the result is not returned/stored correctly
        ↓
client retries
        ↓
the underlying tool executes again

For tools with external side effects, this means the action itself can happen twice even though there was only one payment.

PayMCP's merged fix stores the paid tool result on disconnect and serves that stored result on retry instead of automatically re-executing the consequential tool path.

The upstream PR explicitly credits the finding:

Reported by Iraitz / LortuArte.

Evidence classification:

• Externally credited engineering finding: YES
• Upstream fix merged: YES
• Independent confirmation that retry ambiguity can cause duplicate consequential execution: YES
• Supports the AEGIS problem statement around stable intent identity and replay handling: YES
• AEGIS dependency used by PayMCP: NO
• AEGIS integration/adoption by PayMCP: NO
• Production validation of AEGIS: NO
• Commercial endorsement of AEGIS: NO

This is published as external engineering impact and problem validation, not as an AEGIS adoption claim.

Full evidence: LortuArte/aegis-sdk — PayMCP external engineering impact

Primary source:

• PayMCP PR #52 — Return the paid result on retry instead of running the tool twice

pip install aegis-core-lortuarte-sdk

Wrap high-risk tools such as payments, trades, paid API calls, or irreversible writes with the AEGIS gate.

from decimal import Decimal
from aegis import AegisLocalPolicyGate

# 1. Initialize the local authorization gate
aegis_gate = AegisLocalPolicyGate()

# Example: authorize this agent for $100
aegis_gate.ledger_data["agent-001"] = Decimal("100.00")


def execute_agent_payment(agent_id, tool_call_id, amount):
    # 2. Authorize spending BEFORE the external side effect
    decision = aegis_gate.evaluar_gasto(
        agent_did=agent_id,
        operation="stripe_charge",
        tool_call_id=tool_call_id,
        amount_usd=str(amount),
    )

    if decision["execution_permitted"] is True:
        # Only now execute the real external action
        # stripe.PaymentIntent.create(...)
        return "Transaction Authorized"

    return "BLOCKED: Policy denied execution"

The important boundary is:

Agent decision
      ↓
AEGIS authorization
      ↓
ALLOW / DENY
      ↓
External tool execution

The financially consequential side effect happens only after authorization succeeds.

AEGIS is not intended to replace LLM gateways.

It addresses a different boundary:

The point where an AI agent is about to turn a decision into an economically consequential action.

Running AI agents that can spend money, trigger payments, execute refunds, access paid APIs, perform trades, or create other financially consequential side effects?

AEGIS Core is currently looking for technical design partners willing to test the authorization boundary against real agent workflows.

Priority use cases:

• 💳 Agent payments and refunds
• 💰 Treasury and credit workflows
• 🔌 Paid API / MCP tool execution
• 🔁 Retry storms and concurrent execution
• 🧾 Duplicate logical actions
• 🤖 Autonomous agent spending
• 🔐 Pre-execution authorization

The objective is not to claim distributed production readiness.

The objective is to test AEGIS against real workflows, identify where the current model breaks, fix those boundaries, and retest them.

pip install aegis-core-lortuarte-sdk

AEGIS Core: https://aegis-api.com/