How We Built Credential Isolation: OBO Auth for AI Agent Tool Execution

The single biggest security mistake in agentic AI today is credential sharing. Most frameworks hand agents a set of API keys and let them call any tool with any credential. A Slack integration and an AWS Lambda invocation use the same service account. A read-only query and a database delete share the same connection string.

We built our platform's credential isolation system in May 2025 to address a recurring anti-pattern we saw across agentic AI frameworks:OPENAI_API_KEY, SLACK_TOKEN, AWS_ACCESS_KEY_IDall sitting in the same environment, accessible to every tool the agent could call. One compromised tool — or one hallucinated tool invocation — and every connected system is exposed.

The Architecture: PlatformCredentialInjector

The core component is PlatformCredentialInjector. It sits between the agent's intent and the tool's execution, and it enforces a simple rule: every tool invocation gets exactly the credentials it needs, scoped to the minimum permission required, for the minimum time required.

Here is the flow:

Step 1: Task-Scoped Token Generation

When an agent needs to execute a tool, PlatformCredentialInjector generates a derivative credential specifically for that invocation. Not a copy of the master credential. A new, scoped token derived from it:

• OAuth scopes are limited to the specific objects and operations the tool needs. A tool that reads a Slack channel gets channels:read on that specific channel — not channels:read across the entire workspace.
• Database connections get role-limited permissions. A tool that runs a SELECT query gets a connection with SELECT-only permissions on the specific table. Not a connection string with DBA privileges.
• Cloud resources get pre-signed URLs or temporary IAM policies. A tool that reads from S3 gets a pre-signed URL for that specific object with a 30-minute expiration. Not an IAM role that can list every bucket in the account.

Step 2: Environment Variable Injection

The scoped credential is injected into the tool's execution environment as an environment variable. The tool sees a credential. It does not know that credential is scoped — it just works for the specific operation the tool needs to perform. No other credentials are present in the execution environment. The tool cannot access credentials for other services, other tools, or other tasks.

Step 3: Time-Limited Expiration

Every scoped credential has a TTL tied to the task duration:

• Read-only operations: 30-minute TTL
• Write operations: 60-second TTL
• Task completion: Immediate expiration regardless of TTL

If a tool execution takes longer than expected, the credential expires and the tool fails safely. If the task completes normally, the credential is revoked immediately — it does not sit around waiting for TTL expiration.

Step 4: Post-Task Cleanup

When a tool execution completes — success or failure — the teardown process runs automatically:

• Environment variables are scrubbed from the execution environment
• Scoped credentials are explicitly revoked (not just left to expire)
• The credential vault records the full lifecycle: issuance, use, revocation
• The Audit System logs the credential scope, duration, and what operations it was used for

On-Behalf-Of (OBO) Authentication

Traditional agent architectures authenticate as the agent. Our platform authenticates as the user, on behalf of the user. This is not just a naming convention — it changes how authorization works throughout the entire system.

When an agent acts on behalf of a user, the scoped credential inherits that user's permissions — not the agent's. If the user does not have permission to delete a production database, the agent cannot delete it either. Even if the agent's logic requests deletion, the OBO credential does not carry that permission.

This matters for compliance. When an auditor asks “who authorized this action,” the answer is traceable to a specific user, through a specific approval gate, with a specific scoped credential. The accountability chain is unbroken.

Why Not Just Use Vault?

We get this question a lot. HashiCorp Vault (and similar secret management tools) solve secret storage and rotation. They do not solve scoping. Vault gives you a secret. It does not generate a derivative credential scoped to a specific tool invocation with operation-level permissions and task-duration TTL.

PlatformCredentialInjector integrates with Vault (and other secret stores) as the source of master credentials. But the scoping, injection, lifecycle management, and audit logging are platform-level concerns that sit above any individual secret management solution.

Integration with the Platform

Credential isolation works in concert with every other platform component:

• OATS tool synthesis: When OATS generates a tool on demand, the tool code never contains credentials. PlatformCredentialInjector handles injection at execution time. If the tool is discarded (the default), the credential is revoked. No credential ever persists in generated code.
• Workflow Builder: Each node in a workflow pipeline gets its own credential scope. A data extraction node cannot use the write credentials from a downstream storage node.
• RBAC: Role-based access control determines which capabilities and tools a user can invoke. Credential isolation enforces that the tool only gets what the RBAC policy permits.
• Audit System: Every credential lifecycle event is logged in the immutable audit trail. Compliance teams can trace any action from the user through the agent through the credential to the system.

The Principle

The principle behind credential isolation is simple: AI agents should have less access than the humans they serve, not more. A human developer uses personal credentials scoped to their role. An AI agent should use derivative credentials scoped to the specific task. The agent is acting on behalf of the user, with a subset of the user's permissions, for a limited time, with full audit logging.

This is how our platform handles security from the credential layer. It is one part of a defense-in-depth strategy that includes sandboxed execution, DLP scanning, HITL approval gates, and immutable audit trails. Each layer reinforces the others.