Every agent action is an answer to one question: on whose behalf did this just happen? The architect who can answer that question precisely — with an identity, a scope, a consent record, and an audit trail — has a defensible program. The architect who cannot has a liability waiting to materialize. In 2026, OAuth scope discipline is the single most-violated control in agent programs. Surveys of enterprise agent deployments through Q1 2026 found that roughly 60-70% of agents in production have at least one over-scoped credential — a token with Mail.ReadWrite when only Mail.Read was needed, a Salesforce session with edit access to all records when only specific record types are required, a Slack bot with chat:write to all channels when one was sufficient. Over-scoping is convenient, deferred, and almost always disastrous when an injection or insider event happens. This lesson is the privacy, identity, and consent layer of the agent control plane: how to wire each agent to act under either a specific human's identity (delegated OAuth) or a system identity (service principal) with consent audit trails; how to align with Entra ID, Okta, Salesforce identity; how to enforce OAuth scope discipline operationally; and how to make every action trace to a who and a why.

The Identity Question

An agent posts a refund to a customer's account. Who is the legal and operational actor? Two answers exist, and they have profoundly different consequences.

Answer one: the human the agent is acting on behalf of. The support agent (Marta Henriques, support lead) logged into the platform. The agent runs under Marta's identity, with Marta's permissions, against Marta's audit trail. The refund posts as "approved by Marta Henriques via Athena." Marta is accountable; her permissions limit the agent; her revocation revokes the agent.

Answer two: the agent itself as a system identity. The agent is a service principal in the identity provider — its own non-human identity with its own credentials. The refund posts as "approved by Athena (service principal id: sp_athena_prod)." A platform admin is accountable for the service principal; its scopes are configured centrally; revocation requires admin action.

Neither answer is universally correct. Each has the right use case, and the architect's job is to choose deliberately rather than by default.

When delegated identity is right

Delegated identity makes sense when:

• The agent's actions should match the specific human's permissions. A sales-ops agent accessing Salesforce should see only what the requesting salesperson sees; a healthcare-record agent should see only what the requesting clinician can see.
• The audit trail must trace each action to a specific human. Healthcare, financial services, legal — sectoral regulation requires per-action human attribution.
• The agent operates per-user. Personal productivity copilots (calendar, email, drafts) acting as me on my data.
• Consent must be per-user. Each user explicitly authorizes the agent's access via OAuth consent screen; the user can revoke unilaterally.

When service-principal identity is right

Service principal makes sense when:

• The agent operates on behalf of the organization, not any individual. A monitoring agent watching production health, a data-pipeline agent running scheduled extracts.
• The agent's permissions are fundamentally narrower than any individual user's. A drafts-only support agent (write internal notes only, never customer-replies) cannot map to any human role because no human's role is "writes only internal notes."
• No human is in the conversational loop. Backend agents triggered by webhooks, schedules, or other agents.
• The agent's scope is permanent and centrally controlled. Per-user consent is the wrong control surface for an agent that is part of the platform.

The hybrid pattern

Many production agents in 2026 use a hybrid: the agent has a service-principal identity for platform-level operations (logging, configuration, secrets) and operates under delegated identity for user-facing actions. The Athena agent might log to Datadog as service principal sp_athena_prod, but when drafting a response for Marta's queue, it reads ticket data through Marta's delegated OAuth session against Zendesk.

OAuth Scope Discipline

OAuth scopes are the second answer to "on whose behalf did this happen." The first answer is the identity; the second is what that identity was authorized to do. Scope discipline is where agent programs in 2026 most often fail.

The problem in numbers

Three surveys of enterprise agent deployments through Q1 2026 (Salt Security's agent OAuth study, Astrix's NHI audit, and Zenity Labs' MCP scope analysis) converge on similar numbers: roughly 60-70% of agents in production have at least one over-scoped credential. The most common over-scoped scopes:

• Microsoft Graph. Mail.ReadWrite where Mail.Read suffices. Files.ReadWrite.All where Files.Read.Selected covers the use case. Calendars.ReadWrite where Calendars.Read.Shared was intended.
• Google Workspace. gmail.modify where gmail.readonly works. drive.full_access where drive.readonly suffices. calendar where calendar.readonly is appropriate.
• Salesforce. full or api with broad object permissions where the agent only needs specific objects and specific record types.
• Slack. chat:write to all channels where chat:write.public to one channel works. files:read across the workspace where channels:history on a single channel suffices.
• GitHub. repo (full control of private repositories) where contents:read on a specific repo works. admin:org where read:org suffices.

Over-scoping is convenient. The developer is iterating; the broader scope just works; the narrower scope requires careful enumeration. The deferral becomes permanent. The agent ships with the broad scope and stays there.

The principle of least privilege, applied

The architect's principle: every OAuth grant is the minimum necessary scope, narrowly written, periodically re-justified. Four practices implement the principle.

1. Scope-by-scope justification at intake. The intake form's question 8 (identity model) requires the agent to enumerate exact OAuth scopes requested AND justify each scope against the action list (question 4). The justification is reviewed by the committee. Generic justifications ("for API access") fail; specific justifications ("Mail.Send to send draft replies to the human reviewer's queue") pass.
2. Scope-narrowing review at first quarterly check. Three months after go-live, the committee reviews the agent's actual scope usage. The observability platform reports which scopes were exercised and which were granted-but-unused. Unused scopes are either documented as necessary-for-edge-cases or removed.
3. Per-resource scoping where supported. Many providers offer narrower scopes via resource specifiers — Microsoft Graph's Sites.Selected, Files.SelectedOperations.Selected, AWS resource-level IAM policies. Use them. The blast radius shrinks proportionally.
4. Conditional access policies. Identity providers (Entra ID, Okta) support conditional access — the scope is granted only when specific conditions are met (IP range, device compliance, time of day, MFA). Apply where appropriate to constrain blast radius.

The over-scoping audit

An audit of an agent's OAuth scopes asks four questions. (1) For each scope granted, what action requires it? (2) Is the scope the narrowest available for that action? (3) When was the scope last exercised by the agent in production? (4) If the scope were removed, what error would the agent produce? Practitioners running this audit in 2026 routinely find 30-50% of granted scopes either unused or replaceable with narrower alternatives. The audit is conducted at the first quarterly review and annually thereafter.

Aligning with Entra ID, Okta, Salesforce

Most enterprise agent programs do not operate in identity isolation. The identity backbone is one of three providers (with Google Workspace as a fourth for Google-centric organizations), and the agent program must align with the organization's existing identity governance.

Entra ID (Microsoft)

Entra ID is the identity backbone for organizations using Microsoft 365, Azure, and Copilot Studio. The native primitives for agent identity:

• App registrations for service-principal agents. Each agent has its own app registration with its own client secret or certificate. Scopes are configured per-app.
• Delegated permissions for delegated-identity agents. The agent prompts the user for OAuth consent at first run; the granted permissions inherit the user's tenant-level policies.
• Conditional access policies. Apply per-app — the agent's service principal can be required to call from specific networks, with specific authentication strength, at specific times.
• Managed identities for agents running in Azure. The platform issues short-lived tokens automatically; no long-lived secrets to rotate.
• Privileged Identity Management (PIM). For agents that need elevated scopes intermittently, scopes are eligible rather than active and require activation with justification.

The architect's discipline: every agent has its own app registration (not a shared one), conditional access policies are applied where the agent's risk tier warrants, and PIM is used for agents whose elevated scopes are episodic rather than continuous.

Okta

Okta is the identity backbone for organizations using a broader SaaS ecosystem (Salesforce, Zendesk, Workday, ServiceNow, etc.). The native primitives:

• OAuth services for app-to-app authentication. Each agent registers as an OAuth app.
• Universal Directory for service-principal storage and group-based scope assignment.
• Workflows for orchestrating consent and approval.
• Adaptive MFA and ThreatInsight for runtime conditional decisions on agent authentication.
• Okta API Access Management (OAuth for APIs) for centralizing scope policy across the agent's downstream API calls.

The architect's discipline: agent OAuth apps registered with descriptive names, group-based scope management, and audit logs centralized through Okta's system log to a SIEM the security team monitors.

Salesforce identity

Salesforce-resident agents (Agentforce, Einstein, custom Apex/Flow agents) typically use Salesforce identity natively. The architect's discipline:

• Connected Apps for OAuth-style external access. Each agent has a Connected App with explicit OAuth scopes and IP restrictions.
• Permission Sets applied to agent users (or "Agent Users" — Salesforce's specific concept for agent identity). Permission sets are narrower than profiles and easier to audit.
• Sharing Rules ensure agents see only records they should see, enforced at the database layer.
• Apex Sharing for programmatic record-level access control.
• Event Monitoring for audit trails of agent actions.

Salesforce identity has the particular property that agents can be granted access at the data-record level, not just at the API-scope level — a powerful but underused control surface.

The unified policy across providers

The architect's job is a unified scope policy that applies across providers even though each provider's native scope language differs. The policy specifies:

• What read access is permitted (and to which data classes).
• What write access is permitted (and which actions specifically).
• What conditions must be satisfied before any scope is exercised (network, MFA, time of day, business hours).
• What audit trail must accompany each action.
• What revocation procedure applies (who can revoke, in what time window, with what effect on in-flight requests).

Consent and Audit Trails

Consent is the third leg of the privacy / identity / consent triangle. Consent is the record that the right human authorized the agent's action.

Per-user consent (delegated identity)

For delegated-identity agents, OAuth consent at first run captures the user's authorization. The consent record includes:

• Identity of the consenting user (UPN, email, user ID in the IdP).
• List of scopes consented to (the exact OAuth scope strings).
• Timestamp of consent.
• Identity provider's verification (signed by the IdP; cannot be forged client-side).
• Re-consent timing — major scope changes trigger re-consent; trivial scope changes do not.

The consent record is filed centrally (in the IdP's consent store, mirrored to the agent program's audit log). When a regulator asks "did the user authorize the agent's access?" the consent record answers.

Workplace consent (Article 26 worker-information obligation)

Article 26 of the EU AI Act requires that workers and worker representatives be informed when a high-risk AI system is deployed in the workplace, before the deployment. The information obligation is distinct from consent — workers do not "consent" to their workplace tools the way customers consent to a service. But the obligation produces an artifact: the worker-information notice that documents what the agent does, what data it processes, what oversight applies, and what rights workers have.

The architect's discipline: a worker-information notice template; each agent deployed in a workplace context (employee monitoring, productivity, evaluation) produces a populated notice; the notice is delivered through the appropriate channel (works council, all-hands, internal portal) before go-live; the artifact is filed in the register.

Affected-persons information (Article 26)

Where the agent's decisions affect natural persons (customers, applicants, citizens), Article 26 requires that the affected persons be informed that an AI system is in use. The notice can be a customer-facing disclosure ("This response was drafted with assistance from an AI agent and reviewed by a human"), a regulatory-style disclosure on a credit decision letter, or a public-facing notice on a government service.

The architect's discipline: each customer-facing agent has a designed disclosure pattern; the pattern is reviewed by Legal and Comms; the disclosure is applied consistently; the audit log records the disclosure was presented.

Audit trail discipline

Every agent action produces an audit-trail record. The record's fields:

• Action identifier — a unique ID for the action.
• Agent identifier — which agent acted (matches the inventory register).
• Identity — whose identity was used (delegated user UPN or service principal ID).
• Scopes exercised — the specific OAuth scopes invoked.
• Consent reference — the consent record that authorized the action (if applicable).
• Action type and target — what was done, against what resource.
• Timestamp — UTC.
• Initiator — what triggered the action (user request, scheduled job, webhook, another agent).
• Business context — ticket ID, case ID, document ID, transaction ID.
• Outcome — success, failure, partial; with response details.

The audit trail is the answer to "on whose behalf did this happen, with what authorization, for what reason." Stored according to the retention discipline from Lesson 2 (six months minimum for Article 26 high-risk; longer where sectoral requires).

Non-Human Identity (NHI) Management

Service principals, app registrations, API keys, OAuth client credentials — collectively "non-human identities" — are the identities that agents use when they are not delegated. NHIs have specific governance needs.

The NHI inventory

Every NHI in use by an agent is registered with: identifier, owning agent (matches the inventory register), purpose, creation date, last-rotated date, scopes assigned, conditional access policies applied, expiration date. The inventory is a separate but linked artifact from the agent register.

Rotation cadence

Long-lived credentials rotate on a schedule. Common practice in 2026:

• Client secrets: 90 days.
• API keys: 90 days.
• OAuth refresh tokens: per provider default (typically 90 days max).
• Certificates: 1-year max, with overlap renewal.
• Short-lived workload identities (Entra managed identities, AWS IAM Roles for service accounts, GCP Workload Identity): no rotation needed; tokens are minutes-long.

The architect's preference: short-lived workload identities wherever the platform supports them. Long-lived secrets are minimized because they are exposure surface.

Vaulting

All long-lived secrets live in a vault — Azure Key Vault, AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, 1Password Secrets, Doppler. Secrets are never in code, never in configuration files, never in environment variables that survive a process restart, never in chat. Vault access is itself audited.

NHI off-boarding

When an agent is retired, every NHI it used is revoked. The decommission runbook for an agent includes the NHI list and the revocation steps. NHIs that persist after agent retirement are exposure surface for no operational benefit.

NHI tooling

Specialized tools in 2026: Astrix Security, Oasis Security, Token Security, Entro Security. Each provides discovery, scope analysis, anomaly detection, and rotation orchestration for NHIs. For mid-market programs, an NHI security tool moves from "nice to have" to "essential" once the agent inventory exceeds 20-30 agents.

Worked Example: The Athena Identity Design

Athena's identity design walks through the decisions.

Identity model choice. Hybrid. Athena posts as service principal sp_athena_prod for internal platform actions (logging, metrics, configuration reads). When reading customer ticket data from Zendesk, Athena operates under a Zendesk-scoped service principal with narrow permissions (tickets:read, tickets:write-notes-only). No delegated identity because Athena's actions (drafts only, never customer reply) do not map to any individual support agent's role.

OAuth scopes. Three scopes in total. (1) Zendesk: tickets:read (read customer tickets); (2) Zendesk: tickets:write but scoped to internal notes only (a custom OAuth scope set up via Zendesk's API permissions); (3) Datadog: logs:write (write to the observability namespace). Each scope is justified against the action list: tickets:read for ticket processing, tickets:write-notes-only for draft posting, logs:write for telemetry.

Conditional access. Entra ID conditional access requires the service principal call to originate from the EU n8n cluster IP range. Calls from any other source fail. This limits blast radius if the secret leaks.

Rotation. Client secret rotates every 90 days through a calendared workflow. Devon owns the rotation; backup procedure documented.

Vaulting. The Zendesk OAuth client secret lives in Azure Key Vault with read access restricted to the Athena service principal. Never in n8n configuration; n8n reads from vault at runtime.

Consent / worker information. Customers are not informed per-ticket because the agent's output is reviewed and sent by a human. The Athena disclosure pattern is reviewed by Legal and Comms; if Athena ever moves to direct-customer-reply, the disclosure pattern activates. Workers (support agents) were informed before deployment via team meeting + intranet post; works council notification not required at this organization's headcount.

Audit trail. Every ticket Athena drafts produces an audit-log record: action ID, agent ID (AG-2026-031), service principal ID, scopes exercised (tickets:read + tickets:write-notes-only), business context (ticket ID), draft content reference, timestamp, outcome. Stored in Datadog (EU region) for 12 months + S3 cold archive for an additional 12 months (24 months total, exceeds Article 26 six-month floor).

NHI inventory entry. sp_athena_prod registered in NHI inventory with owner Devon Park, agent AG-2026-031, scopes listed, rotation date, expiration date, conditional access policy applied.

The combination — identity model + scope discipline + conditional access + rotation + vaulting + audit trail — produces an Athena deployment that is fully defensible. When the audit committee asks "on whose behalf did Athena draft this response?" the answer is "sp_athena_prod, with tickets:read and tickets:write-notes-only scopes, from the EU n8n cluster, against ticket ZD-2026-148729, on 2026-05-12 at 11:23:47 UTC." Precise, complete, irrefutable.

Anti-Patterns and How to Avoid Them

The shared service principal

Multiple agents share one service principal because creating new app registrations is friction. Result: one over-scoped identity used by N agents, no per-agent audit trail, no per-agent revocation path. Remediation: every agent gets its own service principal at intake; the platform's credential workflow refuses to issue credentials without a registered agent ID.

The over-scoping habit

The developer requests broad scopes for convenience and the broad scopes stay forever. Remediation: scope-by-scope justification at intake, scope-narrowing review at first quarterly check, observability platform reports actual usage, unused scopes removed.

The forever-token

A client secret created for a proof-of-concept agent in 2024 is still valid in 2026. The agent was retired but the secret was never revoked. Remediation: NHI inventory with expiration dates and rotation cadence; off-boarding runbook that includes revocation; periodic sweep for orphaned NHIs.

The plain-text secret

The OAuth client secret is stored in an n8n environment variable, a GitHub secret, a Notion page, a shared password manager entry. Remediation: vault everything; secrets are injected at runtime only; CI/CD reads from vault, never from repository.

The missing consent

The agent processes customer data without a documented consent or lawful basis. Remediation: privacy review at intake captures the lawful basis (GDPR), consent records (where required), and disclosure pattern (Article 26 affected-persons information).

The audit trail gap

The agent acts but the action is not logged in a way that traces to identity + scope + reason. Six months later the question "who authorized this?" has no answer. Remediation: the audit-trail discipline from this lesson, with all ten fields, stored per the retention policy.

Key Takeaways

• Every agent action answers "on whose behalf?" — either delegated (acts as a specific human via OAuth) or service principal (its own non-human identity). Many agents are hybrid (service principal for platform-level; delegated for user-facing data).
• OAuth scope discipline is the single most-violated control in 2026: 60-70% of production agents have at least one over-scoped credential (Mail.ReadWrite when Mail.Read suffices, etc.). The remediation: scope-by-scope justification at intake, scope-narrowing review at first quarterly, per-resource scoping where supported, conditional access policies.
• Identity providers offer native primitives the architect uses: Entra ID (app registrations, delegated permissions, conditional access, managed identities, PIM); Okta (OAuth services, Universal Directory, Workflows, OAuth for APIs); Salesforce (Connected Apps, Permission Sets, Sharing Rules, Apex Sharing, Event Monitoring). The unified scope policy operates across providers.
• Consent and audit trails: per-user OAuth consent for delegated identity (consent record with IdP signature filed in audit log); worker information obligation under Article 26 for workplace deployments; affected-persons information for customer-facing decisions; ten-field audit-trail record for every action.
• Non-Human Identity (NHI) management: dedicated inventory linked to agent register, rotation cadence (90 days client secrets/API keys, short-lived workload identities preferred), vaulting (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault), off-boarding runbook on agent retirement, specialized NHI tooling (Astrix, Oasis, Token Security, Entro) essential past 20-30 agents.
• Worked Athena example: hybrid identity model, three justified scopes (tickets:read, tickets:write-notes-only, logs:write), conditional access by IP, 90-day rotation, Key Vault, 24-month audit trail, NHI inventory entry. The combination produces a precise irrefutable answer to "on whose behalf did this happen?"
• Six anti-patterns: shared service principal, over-scoping habit, forever-token, plain-text secret, missing consent, audit-trail gap. Each has a specific remediation in identity governance and inventory discipline.