Cloud Services Technical Explainer

How do I identify whether cloud activity came from a linked third-party service?¶

A cloud provider may record an event against the user's account even when another service generated the technical request.

The bridge is usually the application identity, delegated permission, consent record, token and request identifiers.

The practical route

Identify the application first, then join the provider's API event to the third party's own job or user record.

Find the stable application identity¶

Do not rely only on a display name.

Preserve, where available:

application/client ID;
publisher or tenant identity;
permission scopes;
consent time;
approving user or administrator;
token activity;
request/correlation ID; and
affected resource.

A provider event might show:

Example API event

User context: dave@northstar.exampleApplication ID: APP-771Operation: ReadFileResource ID: DOC-4402Request ID: REQ-9918

That supports an application-level route even though the user account appears in the same record.

Permission and use are separate questions¶

An application may have permission to read files without ever reading this file.

So separate:

Consent / permissionWhat the app was allowed to doCapability granted to the application.

API eventWhat the provider recorded it doingActual request against a resource at a time.

Both can matter.

Treat the linked service as another evidence holder¶

The third party may retain:

its own user account;
source event;
job history;
request ID;
device or source connection;
workflow configuration; and
export or destination details.

Join those records to the primary provider event where possible.

Revocation needs its own verification¶

Changing the user's password may not remove every delegated token or application credential.

If access is revoked, preserve both sides first where operationally possible and then verify the application actually lost access.

How do I identify whether cloud activity was automated? covers the related question where software rather than a human creates the later event.

The practical point is: a user label can describe the authority under which an application acted. Follow the stable application and request identifiers before attributing the event to the person.