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

```typescript
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](/guides/agent-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](/docs/ai/eve/channel-auth) | See the check that runs before a session exists |
| [Authorizing tool calls for Eve](/docs/ai/eve/authorize-tool-calls) | Authorize tools outside the prompt |
| [Eve](/docs/agent-frameworks/eve) | Run the channel sample |
| [API keys and M2M for Eve](/docs/ai/eve/api-keys-and-m2m) | Keep the secret out of the Eve process |