@irelia0nerf3Shipped: REX Guard — Verifiable Controls for AI Agents
We’re a small engineering team in Brazil building REX Guard — Auditable Authority for AI-Initiated Actions at FoundLab.
We’re working on a problem we believe deserves more attention: when an AI agent initiates a financial operation, how do we verify that it was actually authorized, executed within its permitted boundaries, and independently auditable?
REX Guard is our attempt to address this at the infrastructure level.
Our architecture separates AI reasoning from execution authority, applies deterministic policies, and defines how cryptographically verifiable evidence should be produced for critical decisions and their outcomes.
We’ve made our reference architecture public because we believe meaningful trust starts with technical scrutiny, not marketing claims.
What we’ve built so far
Alongside the architecture, we’ve developed an interactive banking demonstration using Google Cloud, Vertex AI, and Google Sign-In. It illustrates AI-assisted financial workflows, consent management, authorization controls, and auditability.
Important clarification: Our demonstration uses Bradesco’s name and visual identity solely as an illustrative banking scenario. It is an independent FoundLab technical demonstration, not an official Bradesco product, deployment, partnership, endorsement, or representation of the bank’s actual systems. All demonstrated banking scenarios are intended for evaluation purposes.
Where we are now
We’re preparing for more demanding technical evaluations and potential pilots involving Tier 1 financial institutions.
We know that a working demonstration and a well-documented architecture are not the same as production validation.
That’s exactly why we’re here.
We’re looking for people who operate real systems on Google Cloud.
If you work with GCP infrastructure, financial services, payments, IAM, cybersecurity, or AI agents, we’d genuinely appreciate your perspective.
We’re especially interested in:
- Engineers willing to review and challenge our architecture.
- Teams open to testing controlled scenarios or exploring a small pilot.
- Feedback on authorization boundaries, latency, integration complexity, failure handling, and audit evidence.
- Design partners who understand the realities of regulated production environments.
We’re not looking for compliments or trying to claim we’ve solved everything.
We’re looking for honest conversations, difficult questions, and opportunities to learn from people who deal with these challenges every day.
Public architecture:
github.com/irelia0nerf/rex-guard-architecture
Interactive banking demonstration (Google Sign-In):
bradesco-rex-guard.web.app/login/
If you’re working on something similar, or see a flaw in our approach, I’d genuinely love to hear from you.
Alex Bolson
Founder & Chief Architect, FoundLab
Don’t trust. Verify.
Comments2
Keeping the AI that suggests a payment separate from the part that is allowed to actually send it is the idea a bank's risk team will understand fastest. For the customers on the other end, that split means an agent that gets confused can propose something wrong, but it can't move their money without permission.
Thanks for asking. This is based only on reading the public document, with no testing, so treat it as a threat-modeling review rather than findings. The enforcement, replay, and failure-state reasoning is solid. I would not try to break the stated invariants. I would try to make the system approve the wrong thing while every check passes.
Also, as the document already admits, a mandatory PEP is only as strong as the guarantee that it is the sole path to the target, and that is a deployment property, not an architectural one.
I think 1, 2, and 3 are the highest risk, because the checks pass but the checked object differs from the real one. Your validation table covers obvious bypasses well, and I would add acceptance scenarios for these semantic gaps.
2 comments
Keeping the AI that suggests a payment separate from the part that is allowed to actually send it is the idea a bank's risk team will understand fastest. For the customers on the other end, that split means an agent that gets confused can propose something wrong, but it can't move their money without permission.
Thanks for asking. This is based only on reading the public document, with no testing, so treat it as a threat-modeling review rather than findings. The enforcement, replay, and failure-state reasoning is solid. I would not try to break the stated invariants. I would try to make the system approve the wrong thing while every check passes.
Also, as the document already admits, a mandatory PEP is only as strong as the guarantee that it is the sole path to the target, and that is a deployment property, not an architectural one.
I think 1, 2, and 3 are the highest risk, because the checks pass but the checked object differs from the real one. Your validation table covers obvious bypasses well, and I would add acceptance scenarios for these semantic gaps.