Your Coding Agent Shipped the App. Who Is Watching It Now?

A year ago, shipping a side project took a few weekends. Today a coding agent writes the API, the database schema and the deploy config in an afternoon, and the app is live before dinner. That part of the loop got dramatically faster. The part after it did not: once the app is in production, you are back to staring at a hosting dashboard and hoping nothing is wrong.

That gap matters more than it used to, because the code is written faster than anyone reads it. Veracode tested AI-generated code against common security weaknesses and found that around 45% of samples introduced a flaw from the OWASP Top 10, with no real improvement in newer models (Veracode). GitGuardian found that commits co-authored by Claude Code leaked secrets at roughly twice the rate of human-only commits (GitGuardian). And in CVE-2025-48757, about one in ten scanned Lovable apps exposed database tables because row-level security was never switched on (case study).

None of this means you should stop building with agents. It means the loop is not finished at deploy. This post shows how to close it: get your production logs somewhere your agent can read them, turn on detections for the attacks small apps actually get, and let the agent propose fixes that you approve.

Build, ship, and then what?

Most AI-built apps go to production with whatever logging the framework prints by default and whatever the host shows in its log viewer. That is fine until something happens. When a bot starts hammering your login endpoint at 3 a.m., or someone discovers that `/api/admin` answers without a session, the evidence is in your request logs. Nobody is looking at them.

Error trackers solve part of this: they tell you when your code throws. They do not tell you that a single IP made four thousand failed login attempts, that someone is walking your URL space looking for `.env` files, or that one client pulled 2 GB of responses from an endpoint that should return a few kilobytes. Those are not bugs in the stack trace sense. They are things happening to your app, and they only show up in logs.

So the missing piece is not another dashboard. It is a place where production logs land, where security checks run against them continuously, and where your coding agent can ask questions about them in the same session in which it wrote the code.

Step 1: log the things that matter

You do not need an observability project. You need one structured log line per request, with a handful of fields that both humans and detections understand: the client IP, the method, the path, the status code, the response size and, for authentication endpoints, whether the attempt succeeded. Ask your agent to add it. A middleware like the one below is usually ten lines in any framework.

Send the lines to LogPulse over the HTTP API, or point an existing OpenTelemetry exporter at the OTLP endpoint. The field names below match the ones the built-in detections look for, so they start working without any parsing rules.

// One structured line per request. Batch these in production.
await fetch('https://api.logpulse.io/api/v1/logs', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.LOGPULSE_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify([{
    level: res.statusCode >= 500 ? 'error' : 'info',
    source: 'web',
    event: `${req.method} ${req.path} ${res.statusCode}`,
    attributes: {
      src_ip: req.ip,
      http_method: req.method,
      url: req.originalUrl,
      status: String(res.statusCode),
      bytes: String(res.getHeader('content-length') ?? 0),
      // on login routes: 'success' or 'failure'
      action: res.locals.authResult ?? '',
    },
  }]),
});

Step 2: turn on the detections small apps need

LogPulse ships with more than 50 built-in detections mapped to MITRE ATT&CK. Most of them are for corporate networks and cloud accounts, but a handful are exactly what a public web app runs into in its first week online. They are created switched off; you choose which ones run.

For a typical AI-built app, start with these: Authentication brute force and Password spraying (many failed logins from one source, or one password tried against many accounts), Web path scanning and Admin endpoint probing (someone mapping your routes and testing what answers without a session), SQL injection probing and Path traversal attempt (classic payloads in the URL), and Large web response volume to one client (one caller pulling far more data than a normal user would, which is what scraping an over-permissive API looks like from the outside).

Every detection that fires adds to a risk score for the IP or account involved. You do not get an alert per rule; once an entity crosses the threshold, LogPulse raises one notable with the evidence attached, and the AI Investigator writes up what happened. For a small app that difference matters: you want one message that says "this IP tried 3,000 passwords and then hit /admin", not forty notifications.

Step 3: give your coding agent eyes on production

This is the step that closes the loop. LogPulse runs a remote MCP server, so the same agent that wrote your app can read its production logs, security findings and service health. Create a personal access token in LogPulse and add the server to your agent:

claude mcp add logpulse --transport http \
  https://api.logpulse.io/mcp \
  --header "Authorization: Bearer lpat_your_token_here"

Cursor, Codex and other MCP clients connect with the same endpoint and token; the MCP server docs have the config for each. From then on you can ask questions in plain language, in the session where you are already working: "Did anything weird happen on the login endpoint since yesterday's deploy?", "Which IPs triggered security detections this week, and what did they try?", "Are the detections actually seeing my request fields?". The agent picks the tools: it searches logs, lists notables, checks whether your fields are parsed, and compares time ranges around a deploy.

Because the agent also has your code open, the answer does not stop at a description. It can see that the brute-force attempts all hit a route without rate limiting and open the file that defines it. Production evidence and the code that caused it end up in the same context, which is the whole point.

Step 4: let the agent propose, and decide yourself

Giving an AI agent write access to your monitoring is a reasonable thing to be nervous about. So it does not get it. Every change an agent makes through LogPulse is a proposal: a new detection, an alert rule, a tuning exception for a noisy rule. LogPulse checks the proposal against your real data first (would this rule have fired, how often, how expensive is the query), and then it waits for a person to approve it, unless you have explicitly told your organization to apply that kind of change automatically. A wrong change can be reverted the same way.

There is a second reason to be careful, and it is worth naming. Logs contain text that attackers control: user agents, URLs, usernames from failed logins. An agent that reads those can be fed instructions by them. The propose-and-approve model means a malicious string in a log line cannot quietly turn off a detection. It still makes sense to be deliberate about which other tools sit in the same agent session, especially anything that can send data out. Simon Willison's writing on the "lethal trifecta" is the clearest explanation of why.

What this costs

Nothing, for most projects at this stage. The Free plan includes 1 GB of logs per day with 7 days of retention, and from today it also includes the full security suite (detections, MITRE mapping, risk scoring, notables), observability for up to three services with anomaly detection and alerts, and the MCP server with proposals. One gigabyte a day is a lot of request lines for an app that just launched.

When the app grows, the paid plans add volume, retention, team members and higher limits; you do not lose any of the loop you set up on the way. The pricing page has the details.

What we will not pretend

Monitoring does not make insecure code secure. If your database has row-level security switched off, the fix is to switch it on, and a detection that tells you someone is scraping it is a consolation prize. Logs also only show what reaches something that logs: requests that go straight to a hosted database API bypass your app and its request logs. Use your platform's own security advisors for configuration, scan your code, and use LogPulse for the part those tools cannot see: what is actually happening to the app once it is live.

If you are building with an agent, the cheapest moment to set this up is right after the first deploy. Ask your agent to add the request logger, connect the MCP server, switch on the six detections above, and then ask it what it sees. Start free, no credit card needed.