TL;DR
- Aurva can tell when an application is doing the wrong thing with the right access. An application can have a valid identity, an approved destination, and a permitted query, but action can still be outside its intended purpose.
- Intent Drift turns runtime context into a security signal. Aurva learns what an application is meant to do, then compares that with how it actually behaves across data, identities, queries, and destinations.
- It is selective enough to be useful in production. On a real customer benchmark: 93% precision, 0.91 F1, 99%+ noise reduction, and 179 ms mean time to detect.
- Every drift comes with the story behind it. Runtime Incidents reconstruct what changed, which sensitive data was involved, whose identity was used, and how the activity unfolded.
- And the response is purpose-aware too. Aurva helps teams contain the risky behaviour without blindly blocking the legitimate workflow.
Introducing Intent Drift
Security controls are good at answering whether an action was allowed. They are much less effective at determining whether that action made sense for the application performing it.
An application can use a valid identity, access an approved system, and connect to a permitted destination while still operating outside its intended purpose. The evidence may exist across application, database, identity, and network activity, but the security team is left to connect it and determine whether data is at risk.
Aurva Intent Drift is built for this gap. It identifies meaningful deviations from expected behaviour and reconstructs the evidence around them, so analysts can see what changed, what sensitive data was involved, and why the activity was flagged.
Expected behaviour is not a checklist. It’s context.
A static rule can tell you whether an action is permitted. It cannot tell you whether the action is appropriate in the context of the application and its purpose.
Here’s how Aurva solves it for you:
Establish what’s expected: Aurva builds an evidence-backed understanding of how an application is expected to operate: what it is meant to do, how data moves through it, the types of queries it performs, and the sensitive data involved. When there is not enough activity to establish that context, Aurva does not guess.
Evaluate what changed: Observed runtime activity is then evaluated against this understanding. A sudden increase in data volume, a new query pattern, a different identity, unfamiliar sensitive fields, or data moving to a new destination may each be unusual. But one unusual action alone does not establish that an application has gone off course.
Look for a meaningful mismatch: Aurva does not treat every unusual action as runtime drift. It looks for multiple changes that point to the same mismatch between an application’s intended purpose and its observed behaviour.
On a real customer benchmark, this approach achieved 93% precision and a 0.91 F1 score. A multi-layer detection pipeline filters out more than 99% of anomalous activity as noise, while identifying qualifying behavioural deviations in a mean of 179 milliseconds.
This selectivity matters because context changes the meaning of an action.
A bulk export may be routine for a reporting service but unexpected for a customer-facing application. An authorized query may still be concerning when it accesses sensitive data unrelated to the application’s function.
See why the behaviour went off course in practice
popbe-app is designed to validate addresses through an external postal lookup service. Contacting that destination was expected. The data sent to it was not.
During one request, the application transmitted government ID numbers, dates of birth, and an authentication token alongside the address information. Each action was permitted, but the overall behaviour no longer aligned with the workflow.
Aurva connected the expected workflow, observed data movement, sensitive fields, identity, and external destination into one Runtime Incident, with evidence supporting the intent drift finding.
The destination matched the application’s purpose. The data sent to it did not.
Fix the drift without breaking the workflow
The safest response is not always to block the access.
Stopping all external traffic from popbe-app would contain the immediate exposure, but it would also interrupt legitimate postal validation. Aurva therefore recommends a proportionate response: restrict the outbound payload to the address fields required for the approved workflow.
When that correction cannot be made immediately, the analyst can temporarily contain access while the application owner fixes the payload.
The remediation plan separates three actions:
- Contain : Stop further exposure.
- `Correct` : Remove unrelated sensitive fields from the request.
- `Verify` : Confirm that the workflow still functions and sensitive data no longer leaves the application.
The analyst reviews and applies the plan through existing infrastructure and security controls.
Investigate the behaviour, not just the alerts
Runtime Incidents shift investigation from reviewing isolated alerts to understanding whether an application’s behaviour still matches its intended purpose.
Security teams begin with the deviation, see the sensitive data and identities involved, follow the runtime path, and move directly to a proportionate response.
The result is a clearer investigation: not just whether each action was allowed, but whether the overall behaviour made sense.
Benchmark methodology: Results are based on a real customer environment, not a synthetic dataset. Precision, F1, noise reduction, and MTTD were measured against [briefly define reviewed or labelled dataset and the start/end points for detection time].
