Alguard
A project offering a two-tier trust architecture for AI agent shopping scenarios. Through physical isolation between an MCP server and a human approval channel, it prevents agents that have been compromised by prompt injection from executing unauthorized purchases.
Timeline (last 90 days)
Alguard is an entry project for the Amazon Developer Hackathon, proposing a two-tier trust architecture for the Alexa+ scenario to block prompt injection risks in agent shopping.
Alguard's core design invariant is: the system that initiates a high-risk operation is never the system that approves that operation, and this rule achieves physical isolation through the service architecture rather than prompts.
Alguard's Tier 1 is an MCP server (mcp_server/server.py) that exposes three tools—attempt_purchase, get_session_status, get_audit_trail—via Streamable HTTP, and no approve tool exists.
Alguard's Tier 2 is an independent FastAPI service (web_api/resolve_action.py) running on port 8010, with an independent OAuth audience and an independent approve scope, and is the only place that can clear the HALTED state.
There is no network path connecting Alguard's Tier 1 and Tier 2, and users need to manually carry the action_id to complete approval in a manual channel.
Alguard's risk engine scoring system includes three dimensions: category severity, anomaly detection, and owner trust score (approve +0.03, reject -0.15).
Alguard's hard rules cannot be bypassed, specifically including: a single transaction over $1000, over $1500 per hour, over $3000 within 24 hours, high-risk categories, retry after HALT within 24 hours, and spending $250 with an unapproved merchant.
For concurrent approvals, Alguard uses a single conditional UPDATE combined with a rowcount == 1 check, guaranteeing mutual exclusion through database atomicity.
Alguard's cross-process deduplication is implemented by having insert_action_if_not_duplicate() complete the check plus insert within a BEGIN IMMEDIATE transaction.
In Alguard, Bedrock is used to generate explanation text but is a non-critical dependency, and its failure does not change the decision result, with the degraded template marking source = local-fallback.
3 more timeline events
All Facts (13)
Alguard's current threshold-based anomaly detection can catch sudden changes but not slow-rising drift, and EWMA drift detection is a targeted supplement.
50%UnverifiedAlguard's core design invariant is: the system that initiates a high-risk operation is never the system that approves that operation, and this rule achieves physical isolation through the service architecture rather than prompts.
50%UnverifiedAlguard's Tier 1 is an MCP server (mcp_server/server.py) that exposes three tools—attempt_purchase, get_session_status, get_audit_trail—via Streamable HTTP, and no approve tool exists.
50%UnverifiedAlguard's Tier 2 is an independent FastAPI service (web_api/resolve_action.py) running on port 8010, with an independent OAuth audience and an independent approve scope, and is the only place that can clear the HALTED state.
50%UnverifiedThere is no network path connecting Alguard's Tier 1 and Tier 2, and users need to manually carry the action_id to complete approval in a manual channel.
50%UnverifiedAlguard's risk engine scoring system includes three dimensions: category severity, anomaly detection, and owner trust score (approve +0.03, reject -0.15).
50%UnverifiedAlguard's hard rules cannot be bypassed, specifically including: a single transaction over $1000, over $1500 per hour, over $3000 within 24 hours, high-risk categories, retry after HALT within 24 hours, and spending $250 with an unapproved merchant.
50%UnverifiedFor concurrent approvals, Alguard uses a single conditional UPDATE combined with a rowcount == 1 check, guaranteeing mutual exclusion through database atomicity.
50%UnverifiedAlguard's cross-process deduplication is implemented by having insert_action_if_not_duplicate() complete the check plus insert within a BEGIN IMMEDIATE transaction.
50%UnverifiedIn Alguard, Bedrock is used to generate explanation text but is a non-critical dependency, and its failure does not change the decision result, with the degraded template marking source = local-fallback.
50%UnverifiedAlguard's red-team demo script (demo/showcase.py) simulates 15 attacks (including category lying, retry laundering of HALT, session_id rotation, NaN amount, consecutive over-limit spending, etc.), all of which are intercepted and outputs ALL ATTACKS HANDLED.
50%UnverifiedThe follow-up directions listed by Alguard's author include: connecting real charges (Checkout/ChargePermissionId), replacing text-heuristic category inference with MCC data, splitting the shared SQLite into per-tier independent storage, and adding EWMA-based drift detection.
50%UnverifiedAlguard is an entry project for the Amazon Developer Hackathon, proposing a two-tier trust architecture for the Alexa+ scenario to block prompt injection risks in agent shopping.
50%