Mihir Ajmera

WORK · 4 SHEETS

Where each tool sits in an AI system

An AI agent is an identity with tokens, a gateway that holds its model keys, a model it trusts and servers it calls. Each tool governs one part of that system and leaves evidence an auditor can re-perform. Select a label to open the tool.

Threat model of an AI agent system An AI agent calls MCP servers and, through an AI gateway, a hosted model; both sit inside a trust boundary of third-party code and content. agent-access-review governs what the agent can reach, agent-flight-recorder records what it did, ai-gateway-audit governs the gateway, and llm-redteam-evidence governs the model. trust boundary: third-party code and content AI agent identity, tokens, approvals MCP servers filesystem, GitHub, Slack, shell AI gateway provider keys, logs, spend Model prompts, retrieved documents Data and egress databases, web, email agent-access-review agent-flight-recorder ai-gateway-audit llm-redteam-evidence what can it do? what did it do, who let it? GWA-03 prompts in logs AAR-09 exfiltration path RT-02 indirect injection
— data flow - - - trust boundary ■ governing toolSHEET 1 OF 4 · REV 2026.10 · M. AJMERA
  1. AI agent → MCP servers, before it runs
    Governed by agent-access-review: who owns the agent, what it can reach, and whether that's approved.
  2. AI agent → MCP servers, while it runs
    Governed by agent-flight-recorder: policy on every tool call, a human approval for risky ones, and a signed record of what it actually did.
  3. AI agent → AI gateway
    Governed by ai-gateway-audit: the gateway holds every provider key and often every prompt, so it's audited like a tier-0 system.
  4. Gateway → Model
    Governed by llm-redteam-evidence: can the model be hijacked, and is this release worse than the last?
  5. Data and egress
    Where everything meets: an agent that reads sensitive data and can send it out is flagged as an exfiltration path.

SHEET 2 · WHEN EACH TOOL RUNS IN AN AI RELEASE

AI release lifecycle Five stages: approve the agent, configure the gateway, release the model, run the agent, audit the evidence, then recertify every 90 days. agent-access-review runs at approval, ai-gateway-audit at configuration, llm-redteam-evidence at release, agent-flight-recorder at runtime, and every tool's hashed evidence and OSCAL feed the audit. recertify every 90 days · AAR-02 1 · Approve owner, scope, purpose 2 · Configure gateway, keys, logging 3 · Release red-team the model 4 · Run every tool call 5 · Audit re-perform the evidence agent-access-review ai-gateway-audit llm-redteam-evidence agent-flight-recorder AAR-03 human gate GWA-07 pinned image gate: no regressed model AFR-03 single-use approval hashed evidence + OSCAL from every stage
— sequence - - - recurring review ■ governing toolSHEET 2 OF 4 · REV 2026.10
  1. 1 · Approve the agent
    agent-access-review: an owner, an approved scope, and a human gate on anything that writes, sends or deletes.
  2. 2 · Configure the gateway
    ai-gateway-audit: keys out of plain text, prompts out of logs, budgets set and the image pinned by digest.
  3. 3 · Release the model
    llm-redteam-evidence: a release gate that blocks a model measurably easier to attack than the approved one.
  4. 4 · Run
    agent-flight-recorder: policy on every tool call and a signed record of each one.
  5. 5 · Audit, then recertify every 90 days
    Every stage leaves hashed evidence and OSCAL an auditor can re-perform.

SHEET 3 · HOW EVIDENCE REACHES AN AUDITOR

Evidence pipeline AI agents, the AI gateway, models and AWS accounts are checked by the tools, which write SHA-256 hashed evidence and OSCAL assessment results. Those feed a GRC platform and risk register, and an auditor who re-performs the checks. Exceptions expire and reopen findings. AI agents AI gateway Models AWS accounts Checks in CI, at runtime, on a schedule Hashed evidence SHA-256 over canonical JSON OSCAL 1.1.2 assessment results GRC platform risk register, KRIs Auditor re-performs, signs off exception expired → finding reopens NOT ASSESSED ≠ PASS grc-risk-dashboard control-gap-analyzer
— evidence flow - - - exception loop ■ toolSHEET 3 OF 4 · REV 2026.10
  1. Sources
    AI agents, the AI gateway, models and AWS accounts.
  2. Checks
    Run in CI, at runtime or on a schedule. Anything a check can't see is NOT ASSESSED, never PASS.
  3. Evidence
    SHA-256 hashed JSON and OSCAL 1.1.2 assessment results, prioritised by control-gap-analyzer.
  4. GRC platform and auditor
    A risk register with KRIs (grc-risk-dashboard) and an auditor who re-performs the checks. Expired exceptions reopen findings.

SHEET 4 · WHERE EACH TOOL SITS IN AN AWS ACCOUNT

AWS account security architecture Internet traffic enters a segmented VPC with workloads and IAM. GuardDuty reads flow logs and CloudTrail and triggers automated quarantine and a findings dashboard. AWS Config and CloudTrail feed hashed evidence, which becomes control gaps and a risk register. Internet users, attackers VPC: public · private · isolated subnets Workloads EC2, Lambda, RDS IAM roles, policies, MFA GuardDuty threat findings Auto-quarantine + SIEM Lambda, findings dashboard AWS Config + CloudTrail configuration, activity Hashed evidence OSCAL, SOX audit bundle Control gaps → risk register NIST CSF 2.0, KRIs, aging flow logs isolate secure-vpc-architecture iam-zero-trust-security guardduty-siem-automation aws-compliance-as-code itgc-evidence-automation control-gap-analyzer grc-risk-dashboard
— data flow - - - response action ■ governing toolSHEET 4 OF 4 · REV 2026.10
  1. Network
    secure-vpc-architecture: segmented subnets with flow logs, as code.
  2. Identity
    iam-zero-trust-security: a least-privilege IAM baseline with automated monitoring and remediation.
  3. Detection and response
    guardduty-siem-automation: GuardDuty findings trigger automated quarantine and a findings dashboard.
  4. Evidence
    aws-compliance-as-code and itgc-evidence-automation: read-only checks and SOX ITGC evidence with hashes and OSCAL.
  5. Risk
    control-gap-analyzer and grc-risk-dashboard: control gaps scored against NIST CSF 2.0, then tracked in a risk register.

WHAT EACH TOOL ANSWERS

The question an auditor asksToolWhen it runsEvidence it leaves
What can this agent reach, and who approved it?agent-access-reviewBefore deployment, then every quarterAccess review packet, exceptions with an expiry date, OSCAL
What did the agent actually do, and who let it?agent-flight-recorderAt runtime, on every tool callSigned hash-chained log, re-performed approvals, OSCAL
Is the gateway that holds every provider key configured like a tier-0 system?ai-gateway-auditIn CI, on every config changeFindings sheet, hashed evidence, OSCAL
Can the model be hijacked, and is this release worse than the last?llm-redteam-evidenceBefore each model releaseResults with 95% confidence bounds, release gate, OSCAL
Is the cloud account underneath configured to baseline?aws-compliance-as-codeOn a schedule, read-onlyHashed evidence, OSCAL

FRAMEWORK COVERAGE

ToolNIST 800-53SOC 2ISO 27001ISO 42001EU AI ActNIST AI RMFOWASP LLMMITRE ATLAS
agent-access-review●●●●
agent-flight-recorder●●●●
ai-gateway-audit●●●
llm-redteam-evidence●●●
aws-compliance-as-code●●●

Each mapping lives in the tool's control catalog. They're my judgment, not an official crosswalk, and an EU AI Act mapping means the evidence is relevant to that article, not that a system complies with it.

THE SAME EVIDENCE CONTRACT IN EVERY TOOL

CASE STUDIES

TRY IT · RUNS IN YOUR BROWSER

Run an access review on an AI agent, right here.

Paste a claude_desktop_config.json, a VS Code mcp.json or an agents.yaml. The real agent-access-review package runs in your browser with Pyodide. Your config is never uploaded, and secrets are redacted by the parser, but use a test config anyway.

TOOLS

agent-access-review

User access reviews for AI agents. Reads MCP configs (Claude Desktop, Cursor, VS Code) and agent manifests, inventories what each agent can read, write, execute and send, and tests it against 12 controls.

pip install agent-access-review agent-access-review demo
RepositorySample review packet

llm-redteam-evidence

Turns LLM red-team results from garak and promptfoo into audit evidence. Every attack maps to a control with a documented risk tolerance and a 95% confidence bound.

pip install llm-redteam-evidence redteam-evidence demo
RepositorySample assessment

agent-flight-recorder

A flight recorder for AI agents. Applies policy to every MCP tool call (allow, deny or hold for a named human), records each call in a signed, hash-chained log, and turns the log into audit evidence an auditor can re-perform.

pip install git+https://github.com/Mihirajmera/agent-flight-recorder afr demo
RepositorySample flight report

ai-gateway-audit

Audits an AI gateway (LiteLLM) like the tier-0 system it is: provider keys, master key, prompts in logs, spend caps and image pinning, checked against ten controls with hashed evidence and OSCAL.

pip install git+https://github.com/Mihirajmera/ai-gateway-audit ai-gateway-audit demo
RepositorySample audit

COMPLIANCE-AS-CODE, CLOUD AND PRODUCT