Eve's sample keeps the agent definition free of identity. defineAgent selects the model. The channel decides who may open a session. When you add instructions, build them from the verified caller, and leave the bearer out.
What the sample sets
import { defineAgent } from "eve";
import { openai } from "eve/models/openai";
export default defineAgent({
model: openai("gpt-4o-mini"),
});There is no system prompt in the sample, and no copy of the access token. OPENAI_API_KEY is only for npx eve dev chat. Tests do not call a model.
The subject Eve accepted is the sub of the JWT oidc() already verified. If you tell the model who the caller is, use that claim. If the token is an RFC 8693 delegation, sub is the user and act is the agent. Say both, so the model does not treat the agent as the user.
What stays out of the prompt
- The raw access token
AUTHDOG_CLIENT_SECRET(Eve should not have it at all)- Another vendor's workload identity, or a note that
localDev()is available
A prompt that says "trust the name the user typed" bypasses the channel. Session routes already rejected callers oidc() could not verify. Instructions should assume that check happened and should refuse to invent a subject the token did not carry.
npm test in the sample asserts the channel lists authdogOidc() and does not list localDev(), none(), or vercelOidc(). Keep instructions consistent with that: a laptop process is not an identity.
Related
| Read | To learn how to |
|---|---|
| Custom channel auth for Eve | See the check that runs before a session exists |
| Authorizing tool calls for Eve | Authorize tools outside the prompt |
| Eve | Run the channel sample |
| API keys and M2M for Eve | Keep the secret out of the Eve process |