Provider Retention, Local Sessions, and the Controls NoirCode Actually Has

Three places can hold data, and they are not configured by one policy file.

1. The NoirCode server on your machine stores sessions, messages, tool results, config, and usage in the local database and state directories.
2. The inference provider receives the requests your session sends. What it stores, and whether it trains on them, is that provider’s account policy.
3. A gateway in between, if you use one, has its own policy. NoirCode Go and a private baseURL are different cases of this.

NoirCode does not offer retention profiles named developer, enterprise, and air-gapped, and it does not delete provider-side prompts after N days. Those knobs would belong to the provider. What you can set locally is which provider is called, which files and commands the agent may touch, and where the endpoint lives.

Local retention

Sessions remain until you delete them. noircode uninstall removes the shared cache and leaves session data, configuration, and state. noircode debug paths shows db, config, state, and log so you can see the files. Compaction keeps a summary of older turns in the session rather than dropping the history.

There is no config key for “store prompts: false” or “store responses: false.” If the session exists, the conversation is in it. Turning off prompt logging is not a separate switch.

Provider retention, as it applies to this app

When the adapter calls a commercial API, that vendor’s terms decide retention and training. Read those terms for the account you connected. NoirCode cannot force a vendor to discard a request it has already accepted.

NoirCode Go documents a narrower default: workspace privacy settings apply, paid endpoints that train on request data are blocked unless you enable them, and the default regions are Europe and the United States. Changing regions or enabling a restricted model is done in the console, under Settings, Privacy. Go is optional. A direct Anthropic, OpenAI, or Gemini connection does not inherit those Go defaults.

A custom provider with package @noircode/ai/providers/openai-compatible and your own baseURL sends the request only to that URL. Retention is then whatever that server does. Hosting it yourself is the configuration that keeps source code off third-party APIs. NoirCode does not install vLLM or Ollama for you.

Stopping a provider or a file

Deny a provider even when a key is present:

{
  "policies": [
    { "action": "provider.use", "resource": "*", "effect": "deny" },
    { "action": "provider.use", "resource": "acme", "effect": "allow" }
  ]
}

The last matching policy wins. Managed policies and Console workspace policies outrank a project file.

Keep secrets out of tool results with permissions:

{
  "permissions": [
    { "action": "read", "resource": "*", "effect": "allow" },
    { "action": "read", "resource": "*.env", "effect": "deny" },
    { "action": "read", "resource": "secrets/**", "effect": "deny" },
    { "action": "shell", "resource": "*", "effect": "ask" }
  ]
}

Build already asks before sensitive environment-file reads. A deny is stronger. None of these rules rewrite a secret that is already inside a source file the agent was allowed to read. There is no secret scanner and no redact-patterns list.

Plugins and MCP servers are additional code with access to the session. Only add packages and servers you trust. A policy can deny integration.use. That is the boundary. Plugins are not sandboxed by a separate privacy profile.

What an audit looks like here

The session records usage events, tool calls, and errors. The server log is a log file, not a metadata-only compliance store with a 365-day audit schema. If you need an export of who called which model, it is not a built-in report. The accurate check is the provider’s dashboard plus the local session.

Use the provider whose retention you accept, point private work at an endpoint you run, and deny reads of credential files before the agent can put them in a prompt.