What is delegated access?¶
Delegated access is a recorded permission relationship allowing another user or application to perform defined actions for an owner or within a user's authority. It preserves distinct identities and scope; it is not the same as sharing the owner's password.
Owner, delegate and event actor answer different questions¶
Priya grants assistant Dave permission to read Northstar's shared mailbox from 1 to 7 September. At 10:18 the provider records Dave's account opening a message in the mailbox. Priya remains the mailbox owner; Dave is the delegate and recorded actor for that event.
Preserve the relationship over time¶
| Proposition | Representative record |
|---|---|
| Who controlled or owned the resource? | Mailbox, folder, calendar or account ownership record |
| Who granted the permission? | Grant/audit event and administrator or owner identity |
| Who or what received it? | Delegate user ID, group, application or service-principal ID |
| What was allowed and when? | Resource, operation, scope, conditions, start/end and removal |
| What was actually done? | Actor/application, session, operation, target, time and result |
Some provider events show both owner and delegate; others emphasise one. Preserve field names and documentation rather than translating both to “user”. Proper delegation usually leaves a permission relationship and separate identity trail, while shared credentials may place activity under one account without a delegate field.
Application access on a user's behalf is one delegated form. The next card separates service-account access, where the workload acts through its own non-human identity.
The point to remember
Delegation separates resource owner, permission recipient and event actor. Fix the scope and valid period, then attribute the particular session or application that used it.
