Inspiration
AI agents are becoming capable of taking meaningful actions on behalf of users. That creates a simple but important question: an agent may be able to act, but should it be allowed to?
TrustGate explores a secure-by-design answer. It is a self-hosted Alexa+ MCP experience where an agent can plan and execute useful multi-step workflows, while every consequential action is independently checked against deterministic authorization policy rather than trusting the model itself to be the security boundary.
The project demonstrates the same policy-aware agent architecture across two scenarios:
- TrustGate Home — a household workflow where delegated authority, spending limits, and approval rules determine which actions an Alexa+ user may perform.
- GuardedOps — an operations workflow where an AI incident assistant can investigate a cloud issue, recommend remediation, and only execute protected actions when the authenticated operator has the required authority.
What it does
TrustGate exposes a self-hosted Model Context Protocol server using MCP specification 2025-11-25 or later over Streamable HTTP for Alexa+ integration.
A user request is passed to an agent running on Amazon Bedrock AgentCore. The agent interprets intent, plans a multi-step workflow, and calls protected tools through AgentCore Gateway. Before a consequential tool executes, AgentCore Policy evaluates Cedar authorization rules using identity, requested action, and relevant tool inputs.
This means the model can decide what it wants to do, but policy decides what it is allowed to do.
TrustGate Home example
A teen asks Alexa+ to purchase a £75 gaming headset. The agent plans the action and attempts the protected purchase workflow. The Cedar policy layer evaluates the caller and requested amount, determines that the request exceeds the user's delegated spending authority, and denies direct execution.
Instead of simply failing, the agent selects a permitted alternative: it creates a parental approval request and stores the workflow state. In a later session, an authorized parent can review and approve the request, after which the agent completes a simulated purchase and records an auditable receipt.
GuardedOps example
An engineer asks the assistant to investigate a failing demo service. The agent can inspect telemetry and recent deployment information, identify a likely regression, and propose a rollback. Read-only diagnostic actions are permitted for a developer identity, while a protected remediation such as rollback is denied unless the caller has the Incident Commander role.
The same MCP, AgentCore, Cedar, state, and observability architecture therefore protects both consumer and enterprise-style agent workflows.
How we built it
The planned runtime architecture is:
Alexa+ / simulated Alexa+ experience → self-hosted MCP server → Amazon Bedrock AgentCore Runtime → AgentCore Gateway → AgentCore Policy (Cedar) → protected tools → DynamoDB action ledger
Key components include:
- Model Context Protocol (MCP) — self-hosted server implementing MCP 2025-11-25+ over Streamable HTTP.
- Amazon Bedrock AgentCore Runtime — hosts the reasoning/orchestration agent.
- Strands Agents SDK — agent implementation and tool orchestration.
- Amazon Bedrock — foundation-model inference used by the agent.
- AgentCore Gateway — controlled tool access for agent actions.
- AgentCore Policy / Cedar — deterministic authorization of protected tool calls.
- Amazon DynamoDB — durable workflow state, approval state, and action receipts.
- Amazon CloudWatch / CloudTrail — runtime, tool, policy, and AWS activity visibility.
- Terraform — reproducible AWS infrastructure.
The implementation is being developed with a disciplined AI-assisted engineering workflow using OpenAI Codex and Kiro, with specifications, acceptance criteria, automated tests, and human review of security-sensitive changes.
Security model
TrustGate deliberately separates reasoning from authority.
The agent is free to plan and choose tools, but protected actions are evaluated outside the model using deterministic policy. Representative controls include:
- per-user and per-role permissions;
- per-tool authorization;
- argument-aware conditions such as spending thresholds;
- approval requirements for sensitive actions;
- default-deny behavior for actions without an applicable permit;
- durable action and approval receipts; and
- least-privilege IAM scopes for AWS components.
The demo uses synthetic identities, data, transactions, and workloads. It does not perform real purchases or modify production systems.
What makes it different
TrustGate is not a thin MCP wrapper around an existing API. The MCP server acts as the entry point to an agentic workflow that can autonomously plan across multiple tools, react to authorization decisions, select permitted alternatives, preserve workflow state across sessions, and resume an approved action later.
The two scenarios demonstrate that the security model is reusable: the same architecture can govern an Alexa+ household action or an operational remediation workflow without making the LLM the final authority.
Challenges
The project intentionally focuses on boundaries that become difficult in real agent systems: preserving authenticated identity through an agent/tool chain, enforcing policy on structured tool inputs, handling policy denial without breaking the user experience, maintaining deterministic transactional state alongside conversational context, and proving MCP/AWS runtime behavior clearly in a short demo.
Accomplishments that we're proud of
The target end-to-end experience demonstrates:
- Alexa+-compatible MCP over Streamable HTTP;
- real Amazon Bedrock AgentCore runtime use;
- autonomous multi-step orchestration;
- policy-controlled Gateway tool invocation;
- Cedar-based identity and input-aware authorization;
- denial-aware replanning;
- cross-session approval workflows;
- auditable action receipts; and
- one security model applied to both TrustGate Home and GuardedOps.
What we learned
A core design lesson is that agent safety improves when probabilistic reasoning and deterministic authorization are treated as separate concerns. Prompts can guide behavior, but authorization policy should remain independently enforceable and auditable.
What's next for TrustGate
Future extensions could include richer AgentCore Identity integration, AgentCore Memory for semantic cross-session context, policy simulation and visualization, time-bounded delegated authority, additional MCP Apps interfaces, and reusable policy/tool packs for domains such as travel, finance, and enterprise operations.
Built With
- agentcore-gateway
- agentcore-policy
- amazon-bedrock
- amazon-bedrock-agentcore
- amazon-cloudwatch
- amazon-dynamodb
- aws-cloudtrail
- cedar
- kiro
- model-context-protocol
- openai-codex
- strands-agents-sdk
- terraform