Authdog

Enriching instructions for Eve

Last updated Oct 21, 2026
View as Markdown

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.

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

Learn more