Many assistants label each message with a role. The system role carries standing instructions, the user role carries requests, and the assistant role carries prior answers.
Names and exact behavior vary by product. Treat roles as a labeling concept, not a standard.
Role | Carries | Example content |
|---|---|---|
System | Standing rules for the session. |
|
User | The request and its facts. |
|
Assistant | Prior answers in this session. |
|
Durable rules belong in the system role. Per-task facts belong in the user role.
Prior assistant text stays in context and can anchor later answers. Correct it explicitly rather than leaving it.
Applications define which instruction roles have authority; consult the chosen platform's documented hierarchy. A later user request is not automatically allowed to override application rules. Separately, models can fail to follow the intended hierarchy, so test adherence rather than treating the hierarchy as a security boundary.
Never rely on priority tricks for safety. State one rule once instead of stacking overrides.
Use least privilege: send the smallest excerpt that answers the task. Keep credentials and secrets out of prompts; share proprietary material only through an account and deployment approved for its data class and task.
Files and logs can carry injected instructions from third parties. A human approves risky actions before they run.
No. Follow the application's documented hierarchy. Model adherence must still be evaluated, and permissions must be enforced outside the model.
As untrusted data. The model summarizes the log, and a human approves any action the log suggests.