Start with the agent's task and the sources it needs. Give the connection an attributable identity, enforce permission checks before returning information, and test both allowed and denied reads. Limit downstream actions separately. Revoking knowledge access can prevent later retrieval; it does not recall returned text or establish that work already dispatched has stopped.
Start with one task and its readers
A support agent drafting from approved troubleshooting guides needs a different source set from an operations agent reviewing internal project plans. Name the intended reader, output audience and allowed actions before connecting either one. A useful answer can still be an inappropriate disclosure to its recipient.
An automated workflow may repeat a mistaken read or action without someone reviewing every step. Reduce that exposure by excluding unnecessary sources and tools. An agent's knowledge access and its ability to send or change information need separate checks.
Give every connection an identity and a mandate
Use an individually attributable, narrowly scoped credential rather than sharing an administrator's connection. Record its owner, permitted sources and operations, and who may expand that scope. Several agents can use shared memory without being entitled to the same information.
Write the intended boundary down, then verify where the system enforces it. A prompt that says 'do not read payroll' is not a substitute for a retrieval path that refuses the read.
Test retrieval and downstream actions separately
Use harmless documents to test permission-aware retrieval: an allowed source, a denied source, and direct reads or source links as well as search. If an allowed document mixes public and restricted material, establish whether the chosen system supports the required section controls. Otherwise exclude it or supply a separately approved version.
For agents that can act, restrict the available tools and destinations, set suitable rate and spend limits, and require human approval for consequential actions. These are controls to establish in the agent runtime and downstream services, not features implied by connecting a knowledge source. OWASP's excessive-agency guidance explains these distinct boundaries.
Plan what revocation will and will not stop
Identify the control that withdraws the connection's access, its propagation behavior, and any separate control that stops the agent runtime. Test a fresh read after revocation and an already-open client where relevant. Do not assume that disabling one key revokes other keys or downstream credentials.
Access revocation does not erase text already returned, recall an external message or prove cancellation of a tool call already dispatched. An incident procedure must check those retained copies and actions separately. Call a control a kill switch only after defining and testing what it actually stops.
Keep evidence for the paths you depend on
Retain the effective identity, source reference, operation, authorization outcome and relevant time where the system supports them. Inspect which paths generate records and who can read those records. Metadata can be sensitive even when document text is excluded. An intact log does not prove that unrecorded paths did nothing; AI access governance also needs accountable owners and coverage checks.
Where HeyBrain fits
When evaluating a HeyBrain agent connection, use the current setup instructions and inspect the available key scopes and sources for your account. Verify one allowed read, one denied read and revocation through the client you intend to use. Treat document retrieval, saved memory and external actions as separate operations.
This guide does not establish universal field-level redaction, complete access-log coverage, runtime cancellation or downstream approval controls in HeyBrain. Ask for evidence of the specific behavior your task needs before adding restricted company information.