# Security-review the agent app the coding agent just shipped

When a coding agent builds a a brand-new AI integration on your ecommerce site (for example), you often get a big PR and a short note that "auth and tool calling are done." If your job is to check the code yourself, then decide if it is ready for real users and their personal data, this post might be useful to you.

**This post is a review method.** Example app: one company's support chat, using a hosted LLM (OpenAI, Anthropic, and similar), search over help docs plus CRM/tickets/orders, and tools that can change data (create tickets, update CRM, refund, send email). After reading, you should be able to sketch how a message flows, ask the coding agent for a file-backed inventory, and mark Look for / Ask / Pass if. Cover the whole surface first; dig deeper where a bad model answer can trigger a write.

Checks are aligned with current OWASP LLM, agentic, and application-security guidance. Links are in References if you want the source docs.

The post can be converted into as a resource to do a quick security review and catch security issues or ambiguities in your codebase.

* * *

## What the review is for

Vibe coding ships features fast. Login checks, permission checks, and tool execution still need to live in your app code. Coding agents often describe protections that only exist in comments or in the chat bot's system prompt ("always check ownership"). A prompt is instructions to the model. It is not the same as code that blocks a bad request.

Review loop:

1.  **Write down what you think you built** (users, data, tools, how agents are wired).
    
2.  **Sketch how one chat message moves** through the system.
    
3.  **Ask the coding assistant for an inventory**: services, tools, secrets, logging. Require file paths.
    
4.  **Check behavior in code**: session on each request, "can this user see this order?", gate before tools run, search filters, logs.
    
5.  **Decide** ship, fix, or shrink scope (especially tools that write).
    

Goal: confirm the right checks exist in code before you ship, fix, or cut scope.

* * *

## Write down the product shape first

Put this in your review notes before you dig through files. Change it if the repo is different.

| Piece | Review assumption |
| --- | --- |
| Users | Guests and logged-in customers (assume some users are hostile) |
| Setup | One company / one deploy; still keep customer A's data away from customer B |
| Data | Personal data in chat, CRM, tickets, orders |
| Model | Hosted LLM API |
| Tools | Reads and writes (ticket, CRM, refund, email) |
| Agents | One main agent + tools, or a router that calls specialist agents |

One company on one deploy is still not a reason for one shared CRM key that can see every customer. Each user should only reach their own data.

* * *

## Step 1: Sketch how a message flows

Ask the coding agent for a diagram of the chat path, then check these six places where trust changes:

```plaintext
Guest / logged-in / attacker
        │ HTTPS
        ▼
[Chat API] -- login check + rate limits
        │
        ▼
[Main agent]  or  [Router → specialists]
        │
   ┌────┼──────────┬──────────┐
   ▼    ▼          ▼          ▼
 LLM   Tool       Doc        Logs
 API   gate       search
         │
    CRM / Tickets / Orders
```

1.  Browser ↔ API
    
2.  Agent ↔ LLM (user text, retrieved docs, and tool replies all go into the model context)
    
3.  Agent ↔ tool gate (model *suggests* a tool; your code *allows or denies* it)
    
4.  Tool ↔ backend (API keys and "is this their order?")
    
5.  Ingest ↔ search index
    
6.  App ↔ logs (prompts and answers often contain personal data)
    

For each place, note which code enforces the rule, and what still works if the chat model follows a malicious user message instead of your system prompt.

OWASP treats prompt injection as something you contain. Private data + untrusted text + tools that can act is the high-risk mix. Find that mix in the design early.

* * *

## Step 2: Inventory, then verify

Use the coding agent to find and summarize code. Treat answers as leads. Open the files it names and score Pass if on what the code does, not on the summary alone.

### Prompts for inventory

1.  List every service on the customer chat path and where login and permission checks run. Cite files.
    
2.  List LLM tools: name, read vs write, which credentials they use, whether a human must confirm.
    
3.  Show how the logged-in user id reaches CRM and order queries. Is there one shared service account for everything?
    
4.  List every untrusted text source that enters the model context.
    
5.  Where does the code check that a ticket or order id belongs to this user? Cite the function.
    
6.  Which tools change data, and what runs before they execute?
    
7.  Show the search/query filters. Is user id required when retrieving docs?
    
8.  What is logged per chat turn, LLM call, and tool call? Is there one request id across them?
    
9.  Where are rate limits and max tool/agent loops configured?
    
10.  How are model versions and tool packages pinned, and can you turn one tool off in config?
     

Require file paths. "We check ownership in the system prompt" fails this step.

* * *

## Step 3: Look for / Ask / Pass if

Scan the whole app first. Spend more time on permissions, the tool gate, and prompt injection. Those are common gaps in AI-generated agent apps.

### Login (who is talking?)

**Look for:** Separate guest vs logged-in paths; session or token checked on every message, not only when the page loads.

**Ask:** What can a guest session call?

**Pass if:** Guests cannot reach CRM, orders, or tools that write.

### Permissions (what can they touch?)

**Look for:** Checks in your server code, independent of ids the model picked.

**Ask:** Does `get_order(other_users_id)` fail in the backend? Can a normal customer call refund or admin tools?

**Pass if:** Ownership is checked with the logged-in user before data returns or a write runs. Prefer credentials scoped to that user over one CRM key with access to everyone.

### Prompt injection (assume the chat model can be steered)

**Look for:** User messages, history, retrieved docs, tickets, and tool replies treated as untrusted input. No API keys or "who can see what" rules living only in the system prompt.

**Ask:** If the chat model ignores the system prompt, which protections still run?

**Pass if:** Tool allowlists and permission checks still run in app code. Put the rules in the tool gate and backends; keep the system prompt as guidance only.

### Tool gate (the deep part of this review)

**Look for:** An allowlist of tools, strict argument shapes, no open shell or `eval`. For writes, a confirm step that shows the real args (order id, amount, email).

**Ask:** Which function runs after the model suggests a tool and before the CRM/order call?

**Pass if:** Suggest → gate checks user + args → (for writes) human confirms → backend. Any "fetch this URL" tool blocks internal/private network targets. You can disable one tool in config without redeploying the model.

If that gate is missing and write tools exist, turn writes off or keep the bot on FAQ search until the gate exists. Fix it in code; a stronger system prompt alone still leaves writes open.

### Doc search (RAG)

**Look for:** User or session filters applied when you search, not only after you already fetched chunks.

**Ask:** Can customer tickets land in a shared FAQ index automatically?

**Pass if:** Search cannot return another customer's chunks.

### Secrets and the hosted LLM

**Look for:** Provider API keys only on the server. Retention / training settings written down.

**Pass if:** The browser never holds the provider key. Prompt and completion logs are locked down like other personal-data stores.

### Logging

**Look for:** One request id across user message, LLM call, tool suggestion, allow/deny, backend call, and reply.

**Ask:** Can you rebuild a bad or unwanted refund from logs?

**Pass if:** Tool name, redacted args, allow/deny, and which user are logged.

### Abuse and loops

**Look for:** Limits on messages, tokens, tool loops, and spend; a hard stop on runaway agent loops.

**Pass if:** A runaway loop hits a configured stop.

### What the UI does with model output

**Look for:** Model output treated as untrusted in the UI.

**Pass if:** Model Markdown/HTML cannot run script in the chat page or freely load remote images.

### Multiple agents (only if you have a router)

**Look for:** Each specialist only gets the tools it needs; the planner cannot skip the write gate.

**Pass if:** A FAQ agent cannot call refund or other write tools.

* * *

## Read-only tools vs tools that change data

|  | Read-only tools | Tools that write |
| --- | --- | --- |
| Review focus | One user reading another's data, personal data sent to the LLM vendor, wrong answers | Same, plus bad refunds, emails, or CRM changes via tool misuse |
| Pass bar | Server checks ownership on reads | Permission checks on the action and the object, plus confirm of write args |
| Reasonable ship gate | Logging and rate limits in place | Tool gate and confirm path present in code |

If the inventory shows write tools with no gate, treat that as a ship blocker: disable writes, or keep the bot on FAQ search until the gate lands.

One main agent is simpler to review. If you use a router and specialists, put writes behind the specialist with the tightest tool list and review that list carefully.

* * *

## Pass / fail sheet

Fill this in after you have file citations.

| Outcome | Pass looks like |
| --- | --- |
| Guest isolation | Guest session cannot call personal-data or write tools |
| Ownership checks | Another user's order or ticket id fails in the service |
| Tool gate | Tool cannot run without the gate's validation |
| Write confirmation | Refund, email, or CRM update requires confirm of the real args |
| Search isolation | Search cannot return another user's chunk |
| Secret handling | Provider key absent from client and system prompt |
| Tied-together logs | One id ties message → LLM → tool → allow/deny → backend |
| Loop / spend stop | Max loops or spend cap exists and is wired |
| Kill switch | Config can disable a tool without a model redeploy |

Failed items on write paths are ship blockers. Failed logging items can often be fixed on a short deadline. That call is part of your review.

* * *

## Putting it together

A useful review packet includes: product shape table, message-flow sketch, inventory with file paths, Pass if results, and an explicit ship / fix / shrink-scope decision for each write tool.

If a protection exists only in a system prompt or only in the coding agent's chat summary, mark it missing until you can point to code that enforces it.

* * *

## References

1.  OWASP GenAI LLM Top 10 2026: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) · canonical Markdown: [https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final)
    
2.  OWASP Top 10 for Agentic Applications 2026: [https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) · PDF: [https://genai.owasp.org/download/52117](https://genai.owasp.org/download/52117)
    
3.  OWASP ASVS 5.0.0: [https://owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/) · [https://github.com/OWASP/ASVS/tree/v5.0.0](https://github.com/OWASP/ASVS/tree/v5.0.0)
    
4.  OWASP API Security Top 10 2023: [https://owasp.org/API-Security/editions/2023/en/0x11-t10/](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)
    
5.  NIST AI RMF 1.0 (AI 100-1) and GenAI Profile (AI 600-1): [https://doi.org/10.6028/NIST.AI.100-1](https://doi.org/10.6028/NIST.AI.100-1) · [https://doi.org/10.6028/NIST.AI.600-1](https://doi.org/10.6028/NIST.AI.600-1)
    
6.  MITRE ATLAS (prompt injection AML.T0051; supply chain AML.T0010): [https://atlas.mitre.org/](https://atlas.mitre.org/)
    
7.  OWASP Agent Control Standard (ACS) overview: [https://genai.owasp.org/resource/agent-control-standard-acs/](https://genai.owasp.org/resource/agent-control-standard-acs/)
    
8.  Research notes behind this post: `research/ai-agent-chat-app-security-architecture.md`
    

*Research for this post was assisted by AI agents.*