Can AGENTS.md actually keep an agent from exposing secrets?

Treat the instruction file as a reminder, not an access control. The agent can follow it most of the time and still fail when it matters. Restrict what its tools and runtime can read, and give it only the permissions needed for the task.

If a secret never reaches the agent, you don't have to rely on it to remember not to repeat that secret. An output filter is still useful as another layer, but it comes after the exposure to the model.

For local development, keep sensitive environment credentials out of files the agent can inspect. Use throwaway or narrowly scoped development credentials where possible, and separate those from credentials used in other environments.

Permissions matter for tool calls too, not just file reads. A sandboxed agent with minimal access has a much smaller blast radius than one running with broad developer or CI privileges.

Hooks or tool wrappers can help by filtering data before it gets returned to the agent. That's a better place for redaction than asking the model to clean up its own answer.

Pattern-based filtering won't necessarily catch every secret, though. Test the filters against the kinds of credentials and log formats you actually use, and don't treat a clean result as proof that the data is safe.

Secret scanning is useful for finding credentials in the repository and its history, especially if they have recognizable patterns. It won't replace access controls, and agent-generated changes still need human review before they go in.