Checking Every Data Exit in a Private Agent Knowledge Stack

Audit private agent knowledge stacks for hidden outbound dependencies, distinguish local storage from runtime egress, and enforce data sovereignty in closed networks.

Checking Every Data Exit in a Private Agent Knowledge Stack

Key takeaways

  • Data residency at rest does not prevent runtime egress: Securing database volumes or local file systems addresses static persistence. Runtime context retrieval, embedding calls, tool execution, and model processing can traverse external network paths.
  • Private knowledge stores feeding remote LLMs constitute egress: Context retrieved from a private repository like Dnotitia AKB and passed via an agent client (e.g., Claude Code, Cursor) to external LLM endpoints transfers protected data outside the security boundary.
  • Embedding text requires payload verification: Text chunks sent to external embedding endpoints transmit raw document contents, not merely vector math.
  • Authorization scopes and network egress controls are distinct: Broad token scopes increase operational blast radius and obscure user intent, but logging call auditability depends on instrumentation rather than scope configuration alone.
  • Systematic inventory and evidence verification are required: Complete boundary isolation requires auditing candidate outbound vectors using synthetic canary tests, positive/negative egress checks, and configuration cross-checking.

Keeping documents on a private server is only one part of evaluating a private agent deployment. Map the complete request path, including retrieval, model calls, integrations, and logs, before deciding which data can leave the environment.


Distinguishing data-at-rest storage from runtime network egress

Evaluating AI agent architectures for data sovereignty requires distinguishing static storage persistence from runtime network egress paths.

Securing knowledge repositories, vector indices, and document stores on private storage volumes addresses data persistence at rest. However, storage-layer isolation alone does not control how data flows when an agent queries context, generates embeddings, or delegates tool execution across integration interfaces.

To illustrate how regulatory frameworks evaluate runtime data transmission, consider the HHS cloud guidance under US HIPAA rules. When a covered entity or business associate engages a cloud service provider (CSP) to process, store, or transmit electronic protected health information (ePHI), the CSP is classified as a business associate. This classification applies even if the CSP processes only encrypted ePHI and lacks decryption keys. Lacking an encryption key does not exempt a provider from compliance obligations, requiring explicit business associate agreements (BAAs) to govern data handling. While HIPAA specifically addresses US healthcare data, it serves as a practical example for infrastructure teams evaluating how regulatory standards view third-party processing, vendor roles, and data custody across external boundaries.


Mapping outbound dependency vectors across candidate deployments

Evaluating an enterprise agent stack requires mapping every potential outbound dependency vector. Rather than assuming all deployments use identical paths, security teams should audit candidate configurations against these eight core exit points:

  1. Document Ingestion, Parsing, and OCR: Audit external OCR services, document conversion tools, or cloud parsing APIs invoked during knowledge intake.
  2. Document and Query Embedding: Verify whether text chunks or user search queries are transmitted to external embedding API endpoints. Inspect payloads to verify whether raw text content is sent off-site before vector conversion.
  3. Agent Client Retrieval Context and Remote LLM Providers: Audit context passed from a private knowledge base (such as Dnotitia AKB) to agent clients (e.g., Claude Code, Cursor, custom clients) and forwarded to external LLM providers. Operating over protocols like the Model Context Protocol (MCP) does not dictate where LLM inference takes place; sending private context to a remote model remains an outbound data exit.
  4. Tools, APIs, Connectors, and Webhooks: Inspect outbound calls made by agent tools, third-party connectors, external search plugins, or webhook triggers.
  5. Logs, Traces, Error Reporting, and Diagnostics: Evaluate telemetry agents, crash reporting services, APM software, and support bundle exports for inadvertent egress of user prompts or retrieved documents.
  6. Backups, Replication, and Object Storage: Trace remote database backup destinations, cross-region replication links, and S3-compatible object storage targets.
  7. Identity and Token Endpoints: Audit OAuth 2.0 / OIDC identity providers, token issuing services, and remote authorization servers.
  8. Package and Model Downloads and Updates: Inspect automated container pulls, package manager registries, and remote model weight downloads (e.g., Hugging Face).

Authorization scopes, auditability, and MCP proxy architectures

In protocol-based agent architectures, security teams should maintain clear distinctions between authorization management, audit instrumentation, and proxy topology based on the MCP security guidance:

  • Broad Authorization Scopes: Broad or omnibus token scopes increase operational blast radius and make user intent harder to discern in high-level access logs. However, whether individual tool invocations or parameters can be audited depends on application logging instrumentation. Token scopes define authorization boundaries, whereas egress proxies enforce network-level egress policies.
  • MCP Proxy Topologies: Distinguish client-side integration proxies from external third-party API proxies. For instance, AKB's companion client proxy is an MIT-licensed local adapter running beside the client, whereas third-party OAuth proxies route operations to external protected resource servers.

Closed-network auditing data flow matrix

Use this illustrative matrix as a template, not a record of a tested deployment. Record the actual endpoint, operator, region, payload, policy, responsible owner, and evidence for every enabled path. Review retention, training use, subprocessors, and contractual exceptions for the selected service.

Initiating ComponentDestination / Operator & RegionPayload (Data Class)Purpose / Retention & Training Policy / Sub-processorsEgress Control / OwnerVerification Evidence
Agent ClientConfigured model endpoint / actual operator and regionRetrieved context chunks, user queryInference; record actual retention, training use, subprocessors, and contract exceptionsNetwork egress proxy / Security TeamProxy metadata and approved synthetic application traces
Ingestion PipelineLocal or External OCR ServiceDocument images, extracted textText extraction; verify data deletion policyFirewall rule / Ops TeamOutbound packet trace
Embedding ModuleLocal / Hosted Embedding EndpointRaw text chunks, search stringsVector generation; verify whether raw text leaves perimeterEgress allowlist / Security TeamRedacted synthetic request evidence
Telemetry AgentAPM / Logging EndpointApp traces, error stack tracesSystem monitoring; verify sensitive data redactionLog filter / Platform TeamRedacted log sample

During audits, test system behavior when external endpoints become unavailable or are blocked by network security policy. Systems should fail gracefully within approved fallback paths rather than silently redirecting traffic to unvetted public endpoints.


Dnotitia AKB: architecture and storage boundaries

For teams evaluating private agent memory layers, Dnotitia develops AKB (Agent Knowledge Base). As documented in the AKB repository, AKB provides versioned organizational knowledge and memory to AI agents via MCP.

Core storage and operational architecture

Technical characteristics documented in the AKB repository include:

  • Git-Backed Versioned Knowledge Store: AKB provides Git-backed document version history alongside PostgreSQL text and metadata storage and configured vector and object storage. Document versioning should not be read as a claim that every table row or binary file resides in Git.
  • Core Engine vs. External Automation: Core AKB functions as a dedicated read/write knowledge store via MCP. It does not itself include an internal knowledge gardener; external automation, data collectors, or ingestion pipelines represent distinct external layers.
  • Protocol Interface and Client Support: AKB provides context over MCP to clients including Claude Code, Cursor, and custom-built agents.
  • Deployment-specific egress controls: Self-hosting and MCP connectivity do not establish an egress boundary. Evaluate the configured clients, model and embedding endpoints, network controls, and observed behavior of each deployment.

Embedding and client processing locations

The AKB README describes an operator-configured embedding endpoint, which may be locally hosted or supplied by an external service. Check where both document chunks and search queries are processed, including retry and fallback paths.

Trace the agent client separately from the knowledge backend. An agent can retrieve from a private AKB deployment and then send that context to a remote model. Document the processing boundary for each hop; the use of MCP does not determine model location.

Licensing boundaries

AKB's core repository operates under the Business Source License (BSL) 1.1, as detailed in the project LICENSE:

  • Its Additional Use Grant permits self-hosted production use below 100 Named Seats, subject to its terms and aggregation across all deployments and controlling, controlled, or commonly controlled entities. Check the LICENSE for the deployed version.
  • Deployments at or above 100 Named Seats, or offering AKB to third parties as a hosted, embedded, or rebranded service at any seat count, require a commercial license from Dnotitia.
  • The companion MCP client proxy is licensed separately under the permissive MIT License.

Practical verification procedures and egress screening checklist

Security engineers should execute concrete verification testing to validate outbound network boundaries before releasing agent stacks into production environments.

    1. Synthetic Canary Testing: Ingest synthetic canary documents containing unique tracking tokens and run sample queries. Trace execution through ingestion, parsing, embedding, context retrieval, model call, tool execution, retry handlers, background tasks, and backup routines.
    2. Positive and Negative Egress Testing: Conduct positive tests to confirm approved destinations operate correctly, and negative tests to verify that attempts to reach unauthorized or forbidden external endpoints are blocked in a fail-closed manner.
    3. Log and Configuration Cross-Checking: Cross-check active network proxy logs and application telemetry traces against component configuration files, firewall rules, and vendor contract terms.
    4. Allowlist Bypass and Direct Connection Audit: Check for direct outbound connections that bypass proxy allowlists (e.g., hardcoded IP connections or non-standard port calls) as standard operational hygiene.
    5. Log Hygiene and Redaction Controls: Ensure evidence logging and diagnostic capture apply strict redaction, access restrictions, and retention limits to prevent storing sensitive user text or authorization tokens in cleartext.

Egress verification constraints

When evaluating audit evidence, keep two key technical limitations in mind:

  • TLS Network Metadata Limits: Network metadata can show destinations and transfer volumes visible at the observation point. It does not establish encrypted payload contents or complete coverage of every route. Use approved synthetic tests and application instrumentation alongside network evidence.
  • Single-Trace Non-Guarantee: A single clean or quiet network trace during initial testing does not guarantee zero egress across all operational triggers, failure fallbacks, or background scheduled tasks.

Verification screening checklist

#Verification FocusEvaluation ObjectiveSource Reference
1Canary Egress TracingIngest canary tokens and trace across all 8 dependency vectorsTeam Operational Audit
2Egress Proxy RoutingEnforce policy allowlists for server-side MCP clientsMCP security guidance
3Payload Text InspectionVerify whether embedding and parsing endpoints transmit raw text off-siteTeam Operational Audit
4Server-Side Scope ChecksValidate authorizations independently on the server sideMCP security guidance
5Fail-Closed FallbackConfirm policy violations fail closed and fallbacks remain within approved pathsTeam Operational Audit
6Cloud Role and Contract AuditEvaluate vendor roles and contracts; BAA where HIPAA applies, otherwise applicable contractual and regulatory requirementsHHS cloud guidance

FAQ

Does self-hosting AKB or a private knowledge base guarantee zero network egress?

No. Self-hosting places storage under the operator’s control; security still depends on configuration and operation. An agent can send private retrieved context to an external model, embedding service, tool, or telemetry endpoint. A zero-egress requirement must cover every enabled and background path, including inference, embeddings, identity, updates, backups, and logs. Configure these within the approved boundary and test their behavior; local inference or a proxy alone is not a guarantee.

How does using cloud LLMs affect data sovereignty when connected to a private knowledge stack?

When an agent client queries a private knowledge store and passes the retrieved context to a cloud-hosted LLM, the data is transmitted off-site for processing. Even if the knowledge store itself is fully self-hosted, sending prompts and context to external model endpoints constitutes an outbound data exit, requiring vendor SLA reviews, data retention audits, and sub-processor evaluation.

What practical steps verify that no unauthorized data leaves an enterprise agent stack?

Use synthetic canary documents, positive and negative egress tests, and network evidence cross-checked with configuration and approved application traces. Policy violations should fail closed; service outages may use only approved fallback paths. Review redaction, access, and retention for evidence logs. Track observed destinations, unresolved paths, and blocking test results. Network metadata or a single quiet trace cannot establish that every payload and background path remains inside the boundary.

Explore Dnotitia AKB

Review how Dnotitia AKB provides Git-backed organizational memory and hybrid retrieval for AI agents via MCP.

Learn More