Prompt capture & privacy

Conduit records metadata about every MCP tool call so an organization has visibility into how its AI tools are used. It does not record tool call arguments or a summary of what the vendor returned — that boundary is fixed, not a toggle an organization can change.

For the audit log API and retention, see the API reference and the Security guide.

---

What is always captured

Every tool call generates a request_log entry with this metadata:

Field	Description
user_id	The authenticated user who made the call
org_id	The organization context
vendor_slug	Which vendor was called (e.g. datto-rmm)
tool_name	The specific tool invoked (e.g. datto_list_devices)
status_code	HTTP status of the response
response_time_ms	End-to-end latency
source	Whether the call came in over MCP or the CLI wrapper
created_at	Timestamp

This metadata answers what tool was used, by whom, and when.

What is never captured

Conduit does not record, under any configuration:

• The tool call’s arguments (the parameters passed to the tool)
• A summary of the tool’s result (the data the vendor returned)
• The user’s prompt, conversation history, or the AI model’s reasoning — that content never reaches the gateway

This is off unconditionally in the code, not a per-organization setting — turning it back on would require a code change that appears in Conduit’s git history. A search query, a ticket ID, or customer data returned by a vendor API never lands in the audit log or its CSV export.

Access control

Audit log access is gated two ways:

1. Role — only admin and owner roles can view the audit log.
2. Scope — users only ever see logs for their own organization.

Retention

Conduit purges request_log entries older than 13 months (395 days). For longer retention or SIEM integration, configure log shipping to Loki, Graylog, or LogScale — the audit log is forwarded as it is written, and the SIEM’s own retention policy then applies.

Frequently asked questions

Does Conduit see the data my tool calls send and receive?

Conduit is a gateway, so a tool call’s arguments pass through it on the way to the vendor and the vendor’s response passes back through it on the way to your AI client — held only in memory for the moment it takes to forward the call, scan the response for prompt-injection patterns, and briefly cache read-only results. That in-transit handling is inherent to any gateway. What Conduit stores is a separate question: by default it records only the metadata above, never the arguments or the response content. Put precisely, your data passes through Conduit to reach your vendor, and Conduit does not keep it.

What does Conduit record about each tool call?

Metadata only — which user, in which organization, called which tool on which vendor, when, whether it succeeded, how long it took, and whether the call came in over MCP or the CLI. That is the complete list, shown in the What is always captured table above. It answers what tool was used, by whom, and when — never the substance of the request or the response.

Could Conduit ever store the contents of my tool calls or their results?

No — not on any plan, and not through any organization setting. Capturing tool-call arguments or a summary of the response is turned off unconditionally in the code, because no capture strategy is compatible with the commitment not to retain your data. The request_log columns that could hold that content are never populated, and turning capture back on would require a code change that appears in Conduit’s git history.

Do my prompts or the AI’s reasoning ever reach Conduit?

No. The Model Context Protocol carries only the tool name, its arguments, and the tool’s result — not your prompt, your conversation history, or the model’s reasoning. Those stay between you and your AI provider and are never transmitted to the gateway. This is a property of the protocol as Conduit implements it, not a configurable setting.