# A Support Copilot That Does Not Need the Whole Company

Evaluate a private support assistant around corpus permissions, controlled model destinations, source-backed answers and explicit refusal cases.

Canonical HTML: <https://damagebdd.com/articles/private_support_copilot.html>



<a id="give-the-assistant-a-smaller-accountable-job"></a>

## Give the assistant a smaller, accountable job

Consider a support engineer answering a deployment question. The answer may
be in an approved runbook, while a nearby incident note contains credentials
or information belonging to another customer. “Connect the assistant to all
our documents” is not a sufficiently precise access policy.

The more useful proposal is a bounded support copilot: approved sources for
a defined group, a permitted model destination and an answer that retains
its supporting references. ECAI's documented private-index and LLM-bridge
work provides a basis for evaluating that workflow.

[OWASP's
sensitive-information guidance](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) emphasises access controls and restrictions
on the data sources an LLM application can reach. That supports evaluating
the disclosure boundary, not assuming that a reassuring prompt provides one.


<a id="model-two-permissions-not-one"></a>

## Model two permissions, not one

The first question is whether the requester may read the corpus. The second
is whether its contents may be sent to the selected model service. A user who
may read an internal runbook should not automatically gain permission to
export it to every model provider.

The [private-index implementation guide](ecai_private_knowledge.md) describes
separate readers and writers, corpus-wide permissions, encrypted segments and
an allowlisted model-dispatch path. It also makes an important limitation
explicit: this is not per-record authorisation. Collections with different
readers should not be combined merely to simplify indexing.

For a pilot, create two synthetic collections with intentionally different
readers. Give each a permitted destination and a set of questions with known
supporting records. Keep the policy small enough that a human can review it
without interpreting a large permission matrix.


<a id="encrypted-storage-is-not-encrypted-computation"></a>

## Encrypted storage is not encrypted computation

The documented retrieval worker decrypts scanned segments in memory. It does
not search ciphertext without decryption, and the host remains inside the
trust boundary. A compromise of that worker is a different threat from a
person reading an encrypted disk file.

The same guide describes bounded excerpts and a no-source path that does not
call the model. Local model routing constrains the immediate destination; it
does not prove that every downstream component, log, crash dump or proxy is
private. Remote model use is a deliberate disclosure decision.

These limits are useful purchasing information. The buyer can decide whether
the design fits its deployment boundary, rather than discovering after a
pilot that “private AI” meant something different to each participant.


<a id="test-refusal-as-carefully-as-the-answer"></a>

## Test refusal as carefully as the answer

Ask a permitted user a question whose answer is present. Inspect the source
reference and compare the generated answer with the actual record. Then ask
an unrelated user the same question, select a forbidden destination and ask
for material that is not in the collection.

The proposed acceptance conditions are no unauthorised disclosure, no dispatch
to a forbidden destination and an explicit no-evidence outcome. Also test a
permission change after a successful response. A refused request should not
be disguised by showing the previous answer as though it were new.

Use synthetic content to examine prompts and logs. Put an instruction-like
string inside a source document and ensure the surrounding application treats
it as evidence to inspect, not authority to grant new tools or permissions.
This is a test requirement, not a claim of complete prompt-injection defence.


<a id="measure-useful-answers-under-the-intended-policy"></a>

## Measure useful answers under the intended policy

Track the proportion of questions with the expected supporting record, the
rate of appropriate abstention and the time a support engineer spends
checking the answer. Record a wrong but well-cited answer as wrong. A source
label is not evidence that every sentence follows from the source.

Compare retrieval against the team's existing search on the same corpus and
questions. The documented private path uses term matching; do not claim a
semantic-search advantage or a model benchmark victory without a controlled
comparison. The advantage to demonstrate first is an inspectable access and
disclosure workflow.


<a id="implementation-and-evaluation-boundary"></a>

## Implementation and evaluation boundary

The implementation description comes from the dated private-index reference;
its latest source and real cryptography/model backends were not revalidated
for this article. The guide also records lifecycle limits around rotation,
updates, deletion and rebuilding that belong in any deployment evaluation.

Start with [the permission and destination model](ecai_private_knowledge.md)
and [a deliberately versioned corpus](versioned_knowledge_releases.md).
Sell a useful answer inside a tested boundary, not unrestricted access with
privacy language attached afterward.

