Skip to main content
Agent-friendly content should be easy for the right agent to find and use. That doesn’t mean every agent should receive every page. Discovery and authorization solve different problems. Files such as llms.txt help agents find content, but they can’t control access to private pages or protect a sensitive value.

​
Use access controls

If content is private, protect the page or site with authentication and authorization. Test access with the same roles and groups your users have. Removing a link from navigation or llms.txt only makes a page less visible. Anyone—or any agent—with the URL may still be able to fetch it. Before publishing, classify content:
  • Public: Safe for anyone to read and reuse
  • User-only: Available to authenticated users
  • Role-restricted: Available only to specific groups
  • Internal: Not part of the user documentation site
  • Secret: Must not appear in documentation, source control, examples, or agent context
If you need to control access to pages, set up authentication and personalization for your site. See Authentication setup in the Mintlify documentation for more information. Store secrets in a secret manager, never in a documentation page. If you accidentally publish a secret, revoke or rotate the value immediately. Even if you edit the page later, the secret is compromised the moment it becomes public.

​
Keep examples safe to copy

Use unmistakable placeholders such as YOUR_API_KEY and explain where readers should supply the real value. Never paste a working credential, private hostname, customer identifier, or production response into an example. Check screenshots too. Browser tabs, account names, email addresses, tokens, and internal URLs can appear outside the area you meant to document. Add automated secret scanning to the repository when possible, but don’t rely on automation alone. Reviewers should ask whether every example is safe to publish and copy.

​
Separate public and private sources

When an agent that helps maintain your documentation has access to both public and private repositories, make the boundaries between them explicit.
  • State which source is canonical for each audience
  • Avoid publishing internal instructions that contradict public guidance
  • Keep pre-release terminology out of public answers until the feature ships

​
Test access by audience

Add access cases to your evaluation set.
  • Can a public user retrieve only public content?
  • Can an authenticated user reach the right private guide?
  • Does an unsupported request cause the agent to guess from internal context?
  • Can an agent retrieve only public content?
Run these checks whenever permissions, connected repositories, or publication settings change.

​
Respond to accidental exposure

If a secret reaches the repository or published site, removing the page is not enough. Revoke or rotate the value, remove it from the public surface, and follow your organization’s incident process. Git history, caches, and copied agent context may preserve the old value. Next up: Keep content agent-friendly over time — Maintain accuracy, terminology, evaluations, and access boundaries as the product changes.