Today, we're launching AIKO Monitor, an application security system that learns how your application behaves, understands relationships between objects, and uses a full picture context to catch and contain issues, or contain attacks and deploy fixes before they finish.

To explain why we built it, we have to explain why today’s security model does not measure up to the modern application development cycle. Code is shipped at an unprecedented scale with AI, as the cost of finding and exploiting vulnerabilities keeps falling. Security, however, still runs on static rules and disconnected tools.

Threat Model Vs. Behavior

Before any tool, rule, or alert, security is about a single question: what would an attacker want from this application, and what would it look like when they came for it?

The answer is different for every application. If you sell GPU compute, the thing worth stealing can be compute and platform functionalities abused. Things like quota over-exhaustion, sandbox escape attempts, different accounts burning through trial credits under the same person, etc. If you build a platform for orchestrating agents, the thing worth stealing is agent capabilities. An agent coaxed into calling tools it shouldn't, crossing tool boundaries, one tenant's agent reaching into another tenant's context and the multitude of other possibilities depending on the application. A threat model is the detailed, written-down answer to that question. Who are the actors in this specific system? What is each of them supposed to be able to do? Which flows are able to touch something valuable? And for each of those flows, what does improper use look like, specifically, as behavior?

The traditional fix is a time-consuming threat modeling exercise, usually a document. If this document is good enough it could be useful for some time. Then the application changes, an endpoint is added, roles are being split, some AI-generated service ships on a Tuesday, and quickly the document describes a product that no longer exists. These models go stale because they're static descriptions of systems that keep evolving.

This is the founding idea behind Monitor. The threat model shouldn’t just be a document. It should be an adapting artifact, built specifically from and for your application.

WAF Has Never Been Enough

Usually with WAF, a request to endpoints like /login, /admin, /api/user/:id, or /checkout is inspected using path patterns, payload analysis, attack signatures, and IP reputation to block, rate-limit, or allow traffic. This model catches plenty of scanners, fuzzers, obvious injections, bot traffic, and yesterday's exploits. Except that, a lot of real application abuse does not look like this at all.

Take a request like this one for example:

Here's a request:

GET /api/invoices/84721
Authorization: Bearer <token>

And the response:

200 OK
{ "id": "inv_84721", "org_id": "org_beta", "amount": 8421.00, "status": "paid" }

Is this a regular request, or a bad actor having access to another user's invoice? We need more context to tell.

A WAF usually answers the question, “Does this request look bad?”, but for application security, we think, a better question that’s worth answering is, “Is this behavior even allowed in the product?”

Every request exploiting these vulnerabilities is well-formed and individually unremarkable, which is why they only become visible as behavior, at runtime, when a system is able to see the whole picture.

2026 - AI Vulnerability Research Era

AI is lowering the cost of vulnerability discovery, exploit development, and adaptation. Public advisories can be spotted in minutes, proofs-of-concept are being generated in hours, failed attempts can be adjusted, and application flows can be tested at a scale that would have been particularly expensive only a few years ago.

Attackers script reconnaissance and exploitation end to end, while most defensive stacks still route everything through human triage where an engineer stitches the outputs of five tools to form a picture of what actually happened, as these attack chains run continuously, at scale, for almost nothing in terms of time and cost.

That’s a different kind of product from what the industry has mostly built, and it’s the gap we built Monitor to fill.

What AIKO Does Differently

AIKO both models threats and learns context from your application's own traffic. Once you get the SDK running on your app, it observes behavior directly rather than reconstructing it from logs, metadata, or inventories. This unique vantage point helps AIKO build a live model of the product and understand which roles exist, which resources belong to which tenants, and what a normal flow through an endpoint looks like.

This model is what makes the invoice request from earlier answerable. Giving your security system some level of autonomy of this level changes what the output looks like. Most security tools detect and call it a day. They surface something like:

Possible API abuse detected. Severity: high.

A more useful output looks like this:

A newly created account attempted cross-tenant invoice access. Most attempts failed. One export endpoint returned data outside the actor's tenant. The actor has been blocked for the application. A missing ownership check has been identified on GET /api/invoices/{id}, and a fix is ready for review.

We also made sure containment happened immediately. If an actor is actively probing a sensitive flow, AIKO can block that specific user through Cloudflare while the investigation is still running. These are targeted actions against a specific actor, written from the incident itself. With the Cloudflare integration, containment happens before the next request does.

Closing the loop

Security workflows were codependent on humans, where they had to be the integration layer between tools. That architecture made sense when attacks moved at human speed. It makes far less sense when both attackers and defenders increasingly rely on automation. This new change demands more on the defensive side than what they’re used to normally.

The loop shouldn’t be just detect, alert, triage, ticket, and fix. It should be detect, decide, contain, investigate, fix then escalate when human judgment is required.

In practice, it might look like installing the SDK, letting AIKO learn the application, optionally connecting to the Cloudflare enforcement and agent remediation integrations, and simply letting the system run this exact loop.

By the time you look, AIKO should already know what happened, why it matters, what action it took, and what fix is ready for review, and maybe–just maybe–an alert brought to you that needs your attention, if at all.

AIKO Monitor is available today.

Try AIKO