Security and platform teams adding provider access without exposing reusable secrets to agents.
Whether Endram provides the runtime control and evidence needed for agent credential broker.
The control gap
Letting an agent retrieve a provider credential turns the control plane into a secret distribution path and makes it difficult to prove which authorized request actually used the token.
Set a narrow product boundary for credential brokering. A workforce vault stores and retrieves general secrets; an agent action broker should accept an allowed decision and produce only the authority needed for its supported execution path. Provider credentials remain in adapter infrastructure, are never placed in decision logs, and are not returned through the grant endpoint.
Adapter support must be explicit. The current implementation supports GitHub issue creation through a server-side adapter and exact repository scope. Composio remains available for managed OAuth connection lifecycle, but a connected integration is not automatically a scoped Endram execution adapter. Marketing and documentation should distinguish those states until each provider path has replay, scope, failure, and evidence tests.
What good looks like
The broker returns a Endram grant rather than the provider credential; a supported server-side adapter consumes it for one decision-bound action.
- Provider-neutral grant contract
- Opaque one-time tokens
- Hash-only storage
- Adapter-side provider credential custody
A production workflow
- Approve the exact request
- Issue an adapter-bound grant
- Consume it atomically
- Call the provider and sign the outcome
Evidence to require
- Decision-to-grant binding
- Adapter and endpoint
- Consumption event
- Provider success or failure
Buyer checklist
- Can the product enforce a decision before the external tool executes?
- Can policy distinguish the agent, delegated user, tool, resource, and environment?
- Can reviewers see the exact requested action and approve it without broadening future access?
- Does every allow, deny, and approval retain the policy version and reason?
Practical answers
Common implementation questions
What does Endram control for agent credential broker?
Endram evaluates the concrete tool call at runtime. It can allow, deny, or pause the call for approval using agent identity, delegated authority, action, resource, environment, and request context.
Does Endram replace the tool's own IAM?
No. Keep native IAM and OAuth scopes as the outer boundary. Endram adds a decision layer for the actions an agent attempts inside those credentials.
Can teams evaluate policies before enforcing them?
Yes. Shadow mode records the decision Endram would make without interrupting the call, so teams can measure impact before switching a policy to enforcement.