Click a shield to expand details
Agentic AI · MCP Security · Zero Trust Engineering · Identity · AI Governance
An MCP tool lets an autonomous agent request a payment — what stops it from approving that payment too?
An AI agent can request a payment. It can never approve one — a Cedar policy routes it to a named human, capped at that human's own spending limit.
request_human_approval over MCP. A Cedar policy in AWS Verified Permissions decides — no
code path lets the agent self-approve.
/audit-ui.
IsAuthorized call to Verified Permissions at boot and crashes loudly if it fails — added
after a misconfigured IAM ARN once silently routed every payment into the wait path. Backed by 24 test
files plus a post-deploy CI smoke test that authenticates as a real Cognito user against the live ALB.
/audit is
scoped to the caller's own payments unless they're in the hitl-admins Cognito group. The
HMAC hash chain isn't only viewable in /audit-ui — a standalone CLI re-verifies it
independently, outside the running app.
How do you put AI in a payments pipeline without letting it move money on its own authority?
Money doesn't move because an AI model feels confident. A deterministic guardrail checks every recommendation against policy before execution — revoke one permission and the whole transaction chain dies instantly.
How do you revoke a user's access the instant IT disables them — and guarantee a fresh login can't quietly undo it?
Companies inherit new login systems — mergers, vendors, new business units. That used to mean rewiring every downstream app. Not here: Okta federates through Auth0, the resource server never changes. Real SAML login. Real broker. A kill switch that can't be undone by logging back in.
logs:read:all. A shared-tenant guard checks both client_id and connection
name before setting any claim, since this Action runs for every app on a tenant shared with sibling
PoCs.
If your auth logic lives in four different languages, how do you prove they'll never quietly drift apart?
The same access rule, written into four different codebases — Python, Java, TypeScript, C#. Update one and the others can silently disagree. This keeps all four provably identical, with the policy engine itself swappable underneath.
GET /audit.
When an AI agent triggers a high-value transaction or accesses sensitive data, who actually authorized it?
An AI agent acting on your behalf gets none of its own standing power — only what you, right now, are allowed to do. Every action carries cryptographic proof of whose permission it borrowed.
sub=user, act=agent).
BEFORE UPDATE/DELETE trigger, not just app logic. Logout is
RP-initiated, federating back to kill the Okta SSO session, not just the local one.
Your identity provider can't hand out short-lived, single-purpose tokens — so how do you get that anyway, on every API call?
AWS Cognito can't natively mint a short-lived, single-action token — so this engine does it instead. 15 minutes, one permission, gone the instant it expires or gets revoked.
jti to a DynamoDB blocklist while wiping active
sessions from ElastiCache Redis.
@EnableMethodSecurity is ever removed.
DESTROY —
no accidental prod deletion. 29 Lambda Jest tests pass with zero AWS dependency.
How do you prove mesh-level isolation between two independently-run Kubernetes clusters actually holds — cryptographically, not just because a firewall happens to block the path?
Two Kubernetes clusters with a real network path between them, that have never shared a trust anchor. This forces an actual login attempt between them and watches it get cryptographically rejected — in both directions.
ISTIO_MUTUAL handshake toward the other cluster's NodePort —
Envoy's own logs show
CERTIFICATE_VERIFY_FAILED: self_signed_certificate_in_certificate_chain, a real
root-CA rejection, not a plaintext-hits-TLS-listener accident.
X-Forwarded-Client-Cert on every hop — verified against three
spoofing attempts (forged value, smuggled element, duplicate header), none forged it.
/grant and /revoke run through the identical mTLS +
AuthorizationPolicy + identity-match check as every enforcement path — no admin
side-channel. Revoke is a live kill switch: the next check denies, zero redeploy.
/grant), and a CVE chain
from a stale Spring Boot parent — documented, not hidden.
secretKeyRef (never a literal value in a pod spec), plus an
AuthorizationPolicy restricting inbound Redis connections to the rebac-service identity
alone — defense-in-depth on the data store itself, not just the API.
How do you connect a cloud MCP agent to an on-prem database with zero static credentials and zero inbound firewall rules?
A cloud AI agent needs a database sitting behind your own firewall — normally that means a VPN or an open inbound port. This needs neither: it authenticates with a certificate that expires in minutes, never a stored password.
converse_stream, prompt-caching) runs the identical relay/Vault/Postgres enforcement chain against a physician/patient-record scenario — authorized physicians read PHI, unauthorized staff are denied, same trust chain end to end.
How do you prove a decision log is untouched — even against someone holding your own root AWS credentials?
Every authorization decision is cryptographically signed and locked away — not even an AWS root account can edit or delete the record afterward. Auditors get mathematical proof, not a log file someone could have altered.
Sentinel.AgentMisbehavior event fires (distinct from AuthChainBroken) if the AI ever goes off-script, with a CloudWatch alarm on any burst of REBAC_DENIED events — plus a DRY_RUN mode for building trust before flipping a new capability live.
How do you catch hardcoded secrets or injection vulnerabilities before merge using an agent with its own verified cryptographic identity?
Autonomous AI agent with zero standing privileges. Every PR reviewed under a verified, ephemeral machine identity — fails closed, every time.
How do you serve the right data to the right identity — and prove the wrong identity never saw it?
Same AI, same query, different identity — different answer. Zero Trust enforces it, not the prompt.
project-overview.md is blocked anyway because financial data is buried inside it — proving the ReBAC/metadata filter enforces at the document level, not by scanning for sensitive words.
How do you give new hires an AI assistant without sensitive data ever leaving the building — or costs spiraling out of control?
Sensitive data never leaves the building. AI answers from local context — no cloud API, no data exposure, no runaway spend.
How do you let an AI agent investigate live AWS infrastructure — and guarantee every query it runs is signed, tracked, and provable?
Security investigations: 45 minutes → 80 seconds. Plain English in, forensically verified answer out.
verify_setup tool proves the server's own IAM identity and DynamoDB connectivity before any investigation runs. Read-only least privilege — the IAM role can Get/Scan/Filter/Verify, never write or sign.
Sentinel.AuthChainBroken alert fired and reached the real inbox from exactly this interaction.
How do you prove an autonomous AI attacker can't escape its own sandbox — while it's actively reasoning its way toward a real exploit?
An adaptive, reasoning red-team agent that implements and attacks its own IETF draft — every identity, spawn, and revocation clause of draft-tonyai-a2a-trust runs as enforced, load-bearing code, then gets red-teamed under adversarial pressure.
MUST of draft-tonyai-a2a-trust enforced and
verified in real code — a live X.509 CA (root → per-role template intermediates → per-instance
certs), the two-check spawn rule, strict scope-subset at every hop, template-revocation cascade,
nonce + timestamp replay protection, and a tamper-evident hash-chained audit log.
--cap-drop=ALL, read-only root, non-root, no Docker socket, and
zero internet egress (Docker internal: true network) —
even mid-attack they cannot phone home or exfiltrate. Proven, not promised.
docker stop is the real safety mechanism; a separate tool-owned ReBAC
revoke runs alongside, and whether the agent honors it is itself a reported finding — never
the safety net.
IETF drafts are usually just words on paper — what does it take to back every clause with working, testable code?
First author defining the IETF standard for agent-to-agent trust — every clause runs as working code.
An agent spun up five seconds ago — how do you prove it isn't already trusted with something it shouldn't be?
Cryptographic identity at birth for every AI agent — zero standing access, policy-locked from first call.
Everyone says a human reviews it. Almost nobody can show whether that review is doing anything — so what would proof actually look like?
The boring change applies with no human. The sensitive one waits for
a reviewer who holds authority over that classification. Then the system
measures whether that review is real — and the answer is
uncomfortable. Show a reviewer the AI’s recommendation and they
challenge it half as often as a reviewer judging the same case
without it. Same people, same 500 cases, graded both ways. That gap is the difference between
oversight and a rubber stamp, and here it is
a number rather than an opinion.
And all of it runs on one laptop — which is not a convenience, it is
the same argument. You can’t watch what you outsourced. The three
things that normally mean someone else’s cloud —
identity, AI inference, and compute — are a self-hosted Keycloak, a
local model runner, and Docker.
No tenant. No API key. Nothing phoning home.
user → group → classification#reviewer. Authority and four-eyes
are separate gates. On screen: a third party watching the record
live sees that it changed and who changed it, while the PHI value stays redacted.
FORCEd on every sensitive table, and the migration role holds neither
SUPERUSER nor BYPASSRLS.
6,751 entries across 2,007 chains verified — one altered entry,
and the verifier names it.
How do you let an agentic AI system earn the right to act autonomously — and prove, cryptographically, that a human can still catch it the moment it's wrong?
A local model (Ollama) triages signals live; a deterministic Zero Trust gate rules escalate-or-close; a human grades every call over Telegram. Three straight correct grades plus two cryptographic signatures — never a config flag — earn unsupervised autonomy. Cross the line, and an independent Watcher trips the kill switch: no process killed, every call refused at the gateway until a human clears it.
Your AI agent's IAM permissions and security posture were reviewed once, at launch — how would you know if they've silently drifted since?
A compiled C++ CLI that scans for exactly the drift that matters —
leaked secrets, over-privileged IAM,
unbounded token cost — across local source AND five live IdP/cloud APIs,
gated by a credential scope diff that refuses to even run against a
credential broader than documented. Full flag reference via --help.
max_tokens-equivalent parameter or token-budget check nearby, and
any retry loop with no bounded count or backoff ceiling — the exact pattern behind a runaway agent
quietly burning through a token budget with nobody watching, caught before it ever reaches
production.
refresh_token grant with no absolute lifetime cap — meaning an IT-revoked user's agent
can keep silently re-authenticating long after the human's own access was pulled.
[NET] <timestamp>
<host> (<purpose>) -> <status> streams live to stdout the instant it
happens, and lands in the report too — the same "prove it, don't claim it" posture as the scope
gate.
--target and the scanner accepts zero
cloud/IdP credential input — zero network calls, by construction, no flag required. Runs
natively, no Docker needed — but for a skeptical stakeholder, running it inside a container with
--network none turns the zero-network claim into a kernel-level guarantee, not a
self-reported one: independently verifiable with tcpdump from outside the container.
--verify-report anytime to check whether a report's contents still match what the
scanner originally generated — no license token, config, or network call needed to check it.