How do you spot an attacker reading too much data?

CorgiBOX keeps its customer information in an in-house application: identity, contract, support history, but also detailed personal data and billing records. Alice works in support. Her role gives her read access to customer files, which is perfectly normal — that is her job.

That morning, her account is compromised. The attacker signs in, clears MFA with a stolen session, opens one file, then a second. Then twenty. Then a hundred. Then a thousand. Nothing is technically abnormal: the account is valid, the session is valid, the entitlement is genuinely granted, and the access path is the usual one.

So at what point does this behaviour become abnormal? The answer is neither "they should have enabled MFA" nor "they should have taken away Alice's right to read many records". An attacker does not always need to obtain a right they do not have: they can simply abuse a perfectly legitimate one, far faster and far more broadly than intended.

Four acronyms show up as soon as externalised authorization is on the table. No need to memorise them: just look at who does what.

The PAP is where policies are administered: which rules do we want to apply? The PDP is the engine that makes the decision from policies, attributes and context. The PEP sits on the real path of the action — application, API, API gateway, access management component, bastion — it asks the PDP and applies the answer. The PIP supplies the information the decision needs: identity, role, organisation, resource characteristics, risk level, business attributes.

An important point: deploying a PDP does not create a behavioural engine. For anyone to know that Alice opened 487 records in five minutes, something must have computed that number. Depending on the estate it comes from the application itself, the API gateway, a telemetry layer, the SOC, a detection engine, an anti-fraud platform or an internal scoring service.

The chain is straightforward: detection produces or enriches a signal, the PDP weighs that signal against policies and business context, the PEP applies the decision on the real action.

Ariovis works with Axiomatics on fine-grained, dynamic authorization. In a target architecture, that kind of engine plays the PDP role: policies are centralized, decisions are made in real time, and identity governance becomes one of the information sources feeding the decision — identities, role model, rules, governance attributes.

The application no longer simply checks that Alice has the Support role: it delegates a sharper question, whether Alice may read this file, with this session, in this context. Legacy applications and SaaS that cannot adapt keep receiving classic entitlements; modern applications delegate progressively more. It is a trajectory, not a switch.

Service accounts are not estate anomalies you tolerate for lack of a better option. They are non-human identities, to be governed and controlled like the others — with different attributes.

In that context, 83,421 reads are perfectly normal. And nobody would think of asking this batch to approve a notification on its phone: trust factors for a non-human identity live elsewhere — workload identity, certificate or cryptographic mechanism, appropriate credential, origin, environment, scheduler, calling application, destination, usage pattern.

A compromised service account should not turn into a universal identity able to query everything technically reachable from the machine. When sensitive paths have enforcement points and rely on dynamic policy, this strongly reduces the opportunities for abuse and lateral movement across the resources actually covered by that policy.

The nuance matters. An authorization architecture does not protect a resource that bypasses the PDP, an unprotected API, direct database access or a technical path left open. That is precisely why, on a Zero Trust trajectory, an API gateway is often a relevant enforcement point for non-human identities: the batch calls the gateway, the gateway asks the PDP, and the question is no longer only "is the token valid?" but "may this technical identity perform this action on this API, in this context?". It is one pattern, not the only possible architecture.

A security policy that blocked every identity reading a lot of data would stop CorgiBOX within one night. The business needs batches, integrations, migrations, backups and bulk processing. That is exactly why security has to understand the business precisely enough to tell expected mass usage from fraudulent usage.

Alice genuinely holds the Support entitlement. The batch genuinely holds massive rights on invoices. So the question is not who reads the most.

It is whether this access remains consistent with the identity, the resource, the action, the context, the behaviour and the level of risk we have decided to accept.