Credential handling
Agents are only worth having if you can be specific about what they are allowed to touch. Yekar.AI's answer is that every tool call acts as a named account you chose, and the credential behind it is encrypted at rest and decrypted only for the moment the call is made.
You choose whose account each tool uses
Each integration on an agent or flow declares its identity mode - a single, deliberate decision per binding:
| Mode | The call acts as | Typical use |
|---|---|---|
| Service | The domain's team account | A shared support inbox, a company Slack workspace |
| Platform | A Yekar.AI-managed account your organization has installed | Capabilities Yekar.AI operates on your behalf |
| Caller | A credential supplied on the API call itself, for that execution only | Your product acting as each of your customers |
The point of the table is the one thing it does not contain: a fallback. If the account you named has no credential, the call fails and says so. It never quietly borrows a different identity to get the job done - which is exactly the failure mode that makes automated access frightening in the first place.
See Integrations & identity for choosing between them.
Credentials your customers supply
If you're building on top of Yekar.AI, caller mode lets each API call carry its own credential so one customer's data is never reachable with another customer's token. Those credentials are encrypted into a grant scoped to a single run or message, deleted when that work reaches a terminal state, and swept within the hour if a process dies before cleanup.
A supplied credential can be a bearer token, a set of named secret fields, or both. Supplied fields replace the stored ones rather than merging with them, so a partial customer credential can never be completed with your organization's half. Fields the integration doesn't declare are dropped before it ever sees them.
You control what happens when no credential arrives, per binding:
caller-required- always act as the caller. No token, no call. This is the isolation guarantee, stated plainly.prefer-caller(default) - use the caller's credential when one is supplied, and otherwise behave exactly likeservice. Safe to run on a schedule.
A firing request can tighten this further for a specific integration, and the stricter of the two always wins.
Every failure names itself so you know which knob to turn: CALLER_CREDENTIAL_REQUIRED, CALLER_CREDENTIAL_EXPIRED, NO_CREDENTIAL_AVAILABLE, CALLER_GRANT_CORRUPT. Full detail in Caller credential errors.
The record says which credential was used
Audit rows distinguish a caller-mode call that used the caller's own credential from one that fell back to your stored account. When someone asks "whose access was this?", the session answers it.
What this does and doesn't cover
Yekar.AI protects a credential up to the moment it is used - and using it is the point of the call. Once a request reaches the vendor, their system holds it under their terms. Yekar.AI also never retries a credential the vendor rejected by substituting your organization's authority: a rejected identity fails as itself.
Where to go next
- Integrations & identity - picking a mode per binding.
- Caller credentials - the API surface for per-customer credentials.
- Audit before effect - the record every call leaves.