Permissions

Jarvis can orchestrate coding runtimes that read local repositories, open local tools, and report progress back into chat. That makes permission discipline part of normal configuration, not an afterthought.

Public rule set

When you configure or troubleshoot Jarvis, assume these rules always apply:

• Do not publish secrets, tokens, cookies, API keys, or database dumps.
• Do not paste private logs or full session transcripts into public issues.
• Do not publish screenshots that reveal private repository paths, personal data, or provider credentials.
• Redact anything that would let another person reuse your access or reconstruct a private workspace.

JARVIS_API_KEY

JARVIS_API_KEY protects access to the Jarvis API.

Treat it like any other credential:

• generate it locally,
• store it in your own environment,
• do not commit it,
• rotate it if you believe it was exposed.

Runtime permissions

Jarvis can launch runtimes that have their own local permission and tool-access model. Public documentation should describe the boundary clearly:

• Jarvis manages sessions and reporting.
• The runtime CLI still controls its own authentication and local execution context.
• Permission prompts or skip-permission behavior may vary by runtime and local user setup.

Privacy and redaction

Redaction matters in three places:

1. Configuration Never share raw .env contents publicly.
2. Logs Trim logs down to the error you need to report and remove secrets first.
3. Support requests Use summary descriptions instead of dumping raw session output when possible.

Public issues and feedback

If you file a public issue:

• include reproducible steps,
• include the Jarvis version if known,
• include sanitized error text,
• exclude private logs, private prompts, and environment secrets.

That keeps the project reviewable without turning public issue threads into a data leak.

Worker tools and privacy

Worker tools such as progress reporting and human escalation are designed to insert compact status updates into Jarvis instead of flooding the main chat with full tool output.

That design helps with both:

• context quality, and
• accidental exposure of sensitive local details.

The optional search_kb tool follows the same principle. If no knowledge base is configured, it should fail safely with an unavailable status instead of exposing paths or private content.

Related pages

• Tools
• Security and privacy
• Configuration reference