[object Object]

Service Account Model

The agent runs as a dedicated service account (Salesforce integration user, Azure managed identity, AWS IAM role) with statically configured permissions. Simple to set up, easy to audit at the identity layer. The trade-off: every user of the agent shares the same effective permissions, so a Sales rep and the VP of Sales talking to the same agent get the same data scope. Good for internal back-office agents with uniform policy (nightly data sync, scheduled report generation). Bad for any user-facing scenario where row-level security matters.

Implementation tip: lock service accounts to a named API client ID, IP-allowlist them, rotate credentials on a 90-day cadence, and disable interactive login.

Delegated Auth (On-Behalf-Of)

The agent acts on behalf of a specific user. The user’s permissions, sharing rules, and field-level security apply. OAuth 2.0 with the urn:ietf:params:oauth:grant-type:jwt-bearer flow or the OBO (On-Behalf-Of) flow in Microsoft Entra are the modern primitives. The agent receives an access token scoped to the user’s session, calls downstream APIs with that token, and the downstream service enforces policy as if the user called directly.

Better security isolation, full audit trail at the user level, and Salesforce/Dynamics audit logs attribute actions correctly. More complex to manage, especially for long-running agents where the user’s session expires mid-workflow. Token refresh requires either an offline refresh token (with its own theft risk) or re-authentication checkpoints in the workflow.

Just-in-Time Tokens

Short-lived tokens (5–15 minutes) issued per task or per tool call. Minimizes blast radius if a token leaks via prompt injection or log scraping. Pattern: the agent requests a narrowly scoped token from a token broker each time it needs to invoke a tool, presenting a signed task description. The broker verifies and issues a token good only for that operation.

Requires token broker infrastructure (HashiCorp Vault, AWS STS with session policies, or a custom service). Adds 50–200ms of latency per tool call. Modern standard for customer-facing agents and any agent with write permissions to financial or PII systems.

OAuth 2.1 + PKCE for User-Initiated Flows

When an agent needs to act on behalf of an end customer (consumer-facing chatbot connecting to the customer’s own bank), use OAuth 2.1 with PKCE. Avoid the implicit flow (deprecated) and password grant (forbidden in 2.1). Store refresh tokens encrypted at rest with envelope encryption.

Common Failure Modes

  • Static API keys checked into prompts or tool definitions — the #1 leak vector in 2025 incident reports.
  • Over-scoped service accounts with System Administrator profile because someone couldn’t be bothered to design least-privilege.
  • No token revocation path when an agent misbehaves — you can’t pull credentials fast enough.
  • Confused-deputy attacks where an agent uses its own elevated permissions to fulfill a low-privilege user’s request.

Model Selection

High-security contexts (finance, healthcare, regulated PII): JIT tokens + delegated auth, full audit. Internal ops agents (data sync, reporting): service account with strict, narrow permissions. Customer-facing conversational agents: delegated auth, JIT tokens, continuous monitoring, and a kill switch wired to your IDP. Match the model to the threat — over-engineering kills velocity, under-engineering kills the company.

[object Object]
Share