Subtitle
Obfuscation alone only delays a copy. This open source gate stops money from moving unless a real human, on a real device, intended that exact payment.
Introduction
AI agents can now read, copy, and take apart app code much faster than a human analyst could. For a banking app, that changes the threat model in a simple way: if the code reaches a phone or a browser, an agent on that device can try to read it offline.
The usual answer is more obfuscation. That answer is incomplete. Obfuscation makes code harder to read, but it does not change what a copy can do once the code is on a device an attacker controls.
BankShield HumanGate starts from a different goal. Do not try to make a banking app unreadable forever. Make a copied app worthless.
The core idea
Move fees, limits, fraud rules, and approval logic to the server only. Keep no secrets in the app. Then money moves only when three proofs are present together:
- Human proof, with a passkey bound to the real domain, so a phishing site cannot reuse it.
- Device proof, with attestation and device binding, so a stolen token on a new device does not work.
- Request proof, with a signed, timestamped, one time nonce request bound to amount and payee, so a replayed request does not work.
If any one proof is missing, money does not move. That is the invariant, and it holds even with full UI source, full public API documentation, and a fully decompiled app.
An agent with copied screens, copied code, a password, or a stolen token cannot produce all three proofs at the same time. So it is stopped at the gate, before it reaches finance code, before it reaches account data, and before it can move money.
What is inside the repo
BankGuard is the repo side of the same idea. It is a policy gateway in code, not a prompt, for agent work inside your own repo, editor, and CI. Finance files are a red zone. Reads return public interface only, with no implementation, constants, SQL, or thresholds. Writes are denied by default and need human finance owner approval. Reverse tools are blocked against finance targets inside that environment. Secrets are never shown raw, and every call is audit logged.
HumanGate is the runtime side. It is a universal gate for any app or website, as a sidecar proxy or middleware in front of finance routes, with the same decision rules across Python, Java Spring, Node, Go, .NET, PHP, Ruby, Rust, mobile, and web.
HumanGate Blocker v2 is a scalable blocker tested against a catalog of 120 attack types, in groups covering web, API, mobile, authentication and session, AI agent, banking fraud, and infrastructure and supply chain attacks.
Public test results
These results are from the public repo, with demo values only, so anyone can run them and check the gate logic without real bank code, real customer data, real secrets, or real keys:
- BankGuard gateway tests: passed.
- BankGuard leak scan: passed, no banned finance pattern found in the agent repo.
- BankGuard hostile agent simulation: 9 hostile attempts denied, 3 safe attempts allowed as interface reads or draft proposals only.
- HumanGate tests: passed, human payment allowed, headless agent payment blocked, stolen token on a wrong device blocked, forged signature blocked.
- HumanGate Blocker v2: 120 attacks tested, 120 blocked, 0 allowed on a sensitive route.
Run the public tests yourself, with Python 3 only, no extra dependencies:
python3 bankguard/tests/test_agent_guard.py
python3 bankguard/scripts/scan_for_finance_leak.py
python3 humangate/tests/test_human_gate.py
python3 humangate_blocker/tests/test_120_attacks.py
How to use it in a real service
Deploy the gate as a reverse proxy or middleware in front of finance routes. Add a policy file for sensitive routes, passkey requirement, attestation requirement, rate limits, and first payee delay. Add client proof: WebAuthn passkeys on the web, Keystore or Secure Enclave keys on mobile, ephemeral session keys after attestation, and request signing with timestamp and nonce.
Then connect the production pieces that the demo does not ship as a finished system: Redis for nonce, rate, and traffic window state, a queue for audit and alerts, and a risk service for device and transaction scoring. Keep finance logic behind the gate, on the server, with hardware security modules and tokenization.
Honest limits
This repo is not a certified banking product on its own. It is built for real financial services when it is implemented properly, with the production pieces above, plus threat modelling, permission based penetration testing, code review, and compliance review. Copying this repo alone does not make a service compliant.
A gate also cannot stop a human who voluntarily gives away a passkey, or an insider with legitimate access who abuses it. Those need limits, dual approval, anomaly detection, and human review behind the gate. It also cannot force an attacker agent on an attacker machine to refuse. It can only make a copied app worthless, because money logic and approval stay on the server.
What I want feedback on
- Where would this gate give false positives for real users, for example a new phone, a new city, or a first time payee?
- What adapter should I add next, and what finance route should it protect first?
- Is the three proof model clear enough from the README alone, or does the first page need a simpler diagram?
Repo and release: https://github.com/rohan-fast-code/bankshield-humangate/releases/tag/v1.0.0
If you are interested in contributing, please see CONTRIBUTING in the repo. Vetting happens first, with a proper GitHub profile check, and only after vetting is a contributor form sent.
Thank you for reading, and please be blunt. I would rather hear a real flaw now than a polite star.
Top comments (0)