The Download Was Permitted. The Full Story Showed an Attack.

A third-party support analyst uses a legitimate account to download thousands of sensitive customer records onto an unmanaged device.

No password was stolen. No vulnerability was exploited. Authentication succeeded, the account was active, and the application permitted the action.

Viewed separately, each system may see only part of the activity.

The identity provider sees a successful login. The application sees an authenticated user accessing data available to the account. The network sees a normal connection to an approved service. An endpoint tool may not see the device at all because it is not managed by the organization.

But the complete story is very different.

The user works for an external vendor. Their assignment requires access to a small number of customer records, not a bulk export. The device is unmanaged. There is no approved migration, support case, project, or ticket that explains why thousands of records needed to leave the application.

The action was technically permitted.

The business never authorized that use of the access.

That difference is where many identity attacks hide.

Legitimate access can still produce an illegitimate outcome

Security teams often think about attacks as failures of authentication or authorization.

An attacker steals a password. A user bypasses MFA. A vulnerability grants access to a restricted system. A privilege escalation gives an identity permissions it should never have received.

Those risks remain important. But many identity attacks no longer begin with an obviously blocked action.

They happen through legitimate identities, valid sessions, and permissions that were previously granted.

A compromised employee account can operate during normal working hours. A malicious OAuth application can use scopes that an administrator previously approved. A contractor can continue using access after the business need has changed. An administrator can make a dangerous configuration change through a trusted session. A legitimate employee can intentionally misuse access that is necessary for their role.

In each case, the individual action may be allowed by the system.

The security question is not only:

Was the action permitted?

It is also:

Was it expected, justified, and appropriate for this identity, on this device, against this resource, at this moment, and for this business purpose?

That is a much harder question.

The action alone rarely explains the risk

Consider a large download of customer data.

It could be part of an approved migration, an investigation, a customer support process, or a legal request.

The exact same action could also indicate:

• A compromised account
• Insider misuse
• Excessive access
• An unauthorized export
• A vendor operating outside its assignment
• Data theft in progress

The application event alone cannot tell you which explanation is correct.

The same is true for other identity activity.

A new administrator could be part of a legitimate onboarding process or an attacker establishing persistence.

A privileged policy change could be an approved emergency response or an attempt to weaken security controls.

A service account accessing a new system could reflect a planned integration or stolen credentials being used to expand access.

The action matters, but the surrounding identity context determines the risk.

Identity detection has become a context problem

The information required to make that judgment is usually distributed across the organization.

The identity provider knows how the user authenticated.

The endpoint platform may know whether the device is managed and healthy.

The application knows which action was performed.

The identity governance system may know why the access was originally approved.

HR knows whether the person is an employee, contractor, or former worker.

The ticketing system may contain an approved project or change request.

The business owner understands what the identity is expected to do.

No single source tells the whole story.

To investigate the download, a security analyst needs to answer several questions:

Identity: Who is the user, and what is their relationship with the organization?

Access: Which permissions does the account hold, and why were they granted?

Device and session: Where did the activity originate, and is the device trusted?

Resource: What information was accessed, and how sensitive is it?

Behavior: Is this activity normal for the identity’s role and history?

Business purpose: Is there an approved assignment, ticket, project, or owner that explains it?

Blast radius: What else can the identity access, export, change, or delete?

Connecting those signals is not just event correlation.

It requires understanding the relationship between identities, permissions, resources, activity, ownership, and business purpose.

That is the identity context Offroad agents build.

Offroad connects information across identity providers, applications, devices, permissions, policies, tickets, ownership records, and activity. The agents investigate whether an action is consistent with the identity’s role and expected purpose, rather than relying only on a static rule or a generic anomaly score.

The outcome should not simply be:

Large download detected.

It should explain:

• Who performed the action
• What information was involved
• Why the activity is unusual or unjustified
• Which signals support that conclusion
• What the potential blast radius is
• What should happen next

The objective is not to claim certainty about intent when the evidence does not support it.

It is to determine whether the activity is expected, suspicious, policy-violating, or likely compromised, and to make the reasoning clear.

Security teams should define outcomes, not rebuild every detection

Most security teams already know the activity they care about.

Tell me when a contractor downloads sensitive information to an unmanaged device.

Watch for administrators exporting customer data without an approved project.

Alert me when a third-party identity accesses systems unrelated to its assignment.

These instructions are easy for an experienced analyst to understand.

Turning them into reliable detections across changing environments is much harder.

A traditional rule requires the team to define each condition in advance:

• Which identities are contractors?
• Which devices are managed?
• Which data is sensitive?
• Which applications are in scope?
• What volume is considered unusual?
• Which projects or tickets create valid exceptions?
• Who owns the business relationship?
• What should happen when information is missing?

The rule also needs to remain accurate as users change roles, contractors rotate, permissions drift, systems are added, and business processes evolve.

Offroad allows security teams to describe the identity activity and outcome they care about in plain language.

The agents translate that objective into the relevant identities, systems, signals, and investigation steps. As matching activity is observed, they gather the available context, evaluate whether the behavior is justified, and explain the conclusion.

The security team defines what it wants to protect.

The agents perform the investigation required to determine whether the activity represents legitimate work or meaningful risk.

Detection should lead directly to action

Finding the incident is only the first step.

The system must also determine what should happen next.

When the evidence strongly indicates that a compromised contractor account is exporting sensitive data, the appropriate response may be to revoke the session, disable the account, restrict access, or contain the activity immediately.

When the evidence is incomplete, the right next step may be to involve the internal owner of the vendor relationship.

But that person should not receive a contextless alert that says:

Suspicious download detected.

They should receive the completed investigation:

• Who performed the action
• Which account and session were involved
• What information was accessed
• Why the behavior appears unjustified
• Whether the device was trusted
• What other access the identity holds
• What the potential impact could be
• Which response is recommended

The goal is not to remove people from every decision.

It is to stop forcing them to reconstruct the entire story manually while the risk continues.

This is the model we are building at Offroad.

Identity attacks often hide behind legitimate accounts, valid sessions, and technically permitted actions.

Detecting them requires understanding the full identity context while the activity is unfolding, then moving directly from that understanding to the right response.

The download was permitted.

The full story showed why it should never have happened.

‍