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 can still fetch it. On Mintlify, hidden: true removes a page from navigation, llms.txt, search, and AI context, but the page is still public at its URL. 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
For internal files that shouldn’t be on your site at all, like drafts or team notes, add them to .mintignore. Mintlify won’t publish them, and nobody can reach them by URL. If you need to control who can read pages, set up authentication for your site. Mintlify’s agent features follow the same rules:
  • On a partly protected site, llms.txt and llms-full.txt list only public pages.
  • Markdown pages, search, and the assistant only return pages the reader’s user groups can see.
  • Your MCP server returns public pages to anyone and protected pages only to signed-in users.
  • Custom skills can be limited to specific user groups with a groups field in their frontmatter.
Check one more file: if your project has an AGENTS.md at its root, Mintlify publishes it at /agents.md. Move it to .mintlify/AGENTS.md or add it to .mintignore. Store secrets in a secret manager, never in a documentation page.

​
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 signed-out reader, or an agent with no credentials, retrieve only public content?
  • Can a signed-in user reach the private guide their group should see, and nothing beyond it?
  • Does an agent connected to your MCP server with a user’s credentials see only that user’s pages?
  • Does an unsupported request cause the agent to guess from internal context?
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. The secret was compromised the moment it became public. Revoke or rotate the value, remove it from the page, and follow your organization’s incident process. Git history, caches, and copied agent context may keep the old value long after you edit the page. Next up: Keep content agent-friendly over time—maintain accuracy, terminology, evaluations, and access boundaries as the product changes.