September 22, 2026

Testing Permissions When Connecting Enterprise Document Sources

Test how document connectors enforce access control, verify propagation latency for revoked access and file deletions, and validate security trimming models before indexing.

Before connecting a production document source, enterprise search, platform, and security teams must validate how a new connector handles access control. The goal is to test, within a defined scope, that authorized users can retrieve the intended information and that unauthorized users cannot recover it through another path. This guide describes an acceptance procedure; it does not claim that a particular connector has already passed it.

Key takeaways

• Test allowed and denied users: A successful import does not prove that document ACL rules are preserved.
• Verify before prompt generation: Check vector chunks, tool call context, and previews before content reaches an LLM, not just in final UI answers.
• Measure propagation bounds: Record effective source change timestamps and polling resolutions to measure revocation latency reproducibly.
• Separate user removal from content deletion: Deactivating an identity should revoke access while preserving shared documents for other authorized users.

Define the permission boundary first

Document the source's access control list (ACL) model: direct sharing, group memberships, inherited folder permissions, external guest access, and link-based access grants. Before running a revocation test, verify the source's effective access independently; removing one direct grant will not restrict access if the user retains permission through an overlapping group, parent folder, or shared link.

Establish a stable identity mapping between source principals and destination users, accounting for external guests and duplicate display names. Explicitly separate the connector's ingestion service account credentials—which often require broad read access—from the end user's individual search and retrieval authorization.

Identify how permission enforcement operates in the destination architecture. Systems may rely on synchronized permission metadata attached to indexed items (early binding), live queries back to the source authorization endpoint (late binding), or a hybrid approach. Do not assume one mechanism is universal. If SCIM is used for identity management, distinguish user and group provisioning from document-level authorization. RFC 7643 specifies the core identity schema, while RFC 7644 details the protocol. Neither standard establishes that a specific document connector enforces source-level access rules.

Use harmless test content with a unique, distinctive string so that unauthorized exposure is easy to identify during testing.

Build a test matrix around real source behavior

The following matrix outlines proposed acceptance requirements for evaluating a connector against real source behaviors, rather than claiming default or shipped platform behavior:

Continue positive-control queries for an unaffected authorized user throughout testing; denying everyone cannot pass an acceptance check. Do not assume every source supports nested groups or identical inheritance rules. Mark unsupported scenarios explicitly. A connector that cannot represent a required access rule needs an alternative configuration or a narrower source scope before launch.

Measure revocation timing reproducibly

To measure revocation latency accurately, establish a reproducible observation protocol using a consistent clock and timezone basis. Record timestamp t0 when the access change is confirmed effective in the source system. If observable, log the time of the source event or polling trigger, as well as the destination permission-index update.

Run repeated retrieval checks at a fixed polling interval for the test identity. Record both the last allowed observation and the first denied observation. Because periodic sampling brackets the transition, calculating the difference between the first denied timestamp and t0 yields an upper bound on that observed transition at that polling resolution, not exact instantaneous latency or a guaranteed global completion time. For example, if t0 occurs at 10:00 under a 5-minute polling interval, and checks yield allowed at 10:04 and denied at 10:09, the observed propagation bound is 9 minutes (for that path and session, the observed transition lies between those checks if access remains consistently denied; this does not establish system-wide revocation). Repeat across paths, sessions, and replicas where applicable. A single denial is insufficient: confirm continued denial over the agreed observation period and record intermittent stale allows. This timing example is purely hypothetical; target windows must be established with the source owner and security team prior to testing, as window acceptance does not imply immediate revocation or grant permission to tolerate unmonitored leaks.

Test both an existing, active session (to check token and cache invalidation) and a newly initiated session for the target user. Do not perform retrieval checks using administrator tokens or broad ingestion credentials.

Validate authorization across all retrieval and agent paths

Authorization checks must enforce access rules before restricted content is retrieved into context or passed to an LLM, not merely before displaying the final user response. An agent answer that refuses to quote a document is not proof that unauthorized content was excluded from the retrieval context. Use approved diagnostic visibility for model context; if diagnostic tracing is unavailable, record the coverage gap explicitly rather than claiming that an answer proves pre-model enforcement.

Audit every path that can expose data or metadata as the test user (never using administrator tokens):

1. Search and discovery: Request the document by known identifier or URL through each supported UI, API, and agent interface. Verify keyword queries, snippet previews, document downloads, autocomplete suggestions, result counts, and facet aggregations. Determine whether document existence itself is classified as sensitive under the source policy.
2. Context and tool calls: Inspect vector search chunks, tool call payloads, and context passed to retrieval-augmented models before generation occurs.
3. Session and cache boundaries: Test cross-user cache isolation and prompt history. Start fresh conversations to distinguish new retrieval operations from previously delivered session data.

A result already delivered to a user cannot be made unseen. Acceptance criteria should separate restricting future retrieval operations from managing retained conversation history and caches under their respective retention policies.

Test deletion and outage recovery

Deleting a source document, removing a user grant, and disabling an account represent distinct lifecycle events. When a document is deleted, verify that its vector embeddings, text chunks, search index entries, and cached context are purged or invalidated according to policy without affecting unrelated documents. Retention and backups may preserve restricted copies under policy; verify they cannot be newly served to unauthorized users. Live-serving withdrawal is distinct from erasing every stored copy.

Simulate source outages, rate throttling, and network interruptions during testing. Execute permission revocations and document deletions while the sync connection is interrupted. Upon restoring the connector, verify that missed permission updates and deletions are reconciled through the documented automatic or operator-assisted recovery process before declaring the connector healthy.

Record a complete acceptance decision

Document each test scenario using a structured record: connector name, version, and configuration; source effective-access snapshot; principal mapping; document identifier and version; tested path; expected versus observed result; timing resolution; redacted evidence references; and final status (Pass, Fail, Not Tested, or Unsupported).

Maintain strict report hygiene: use synthetic principal and document identifiers, omit credentials or confidential payloads from screenshots and logs, and restrict access to collected evidence logs.

Any unauthorized disclosure outside the agreed access policy constitutes a test failure, regardless of whether other scenarios pass. If a connector cannot support a required source access rule, treat that gap as a deployment blocker or formally restrict the connector's source scope.

Apply checks to the selected platform

Seahorse Cloud offers tenant isolation and API-key authentication primitives. While relevant for platform security, API-key authentication and multi-tenant separation do not prove that a connector correctly maps source-level access control lists, enforces per-user delegated access, or guarantees specific revocation windows.

Evaluate platform capabilities by requesting versioned documentation and test evidence for the specific connector. Verify where permission trimming occurs (index level vs. query time), how ACL updates propagate, and how sync failures are surfaced.

FAQ

Does API-key authentication preserve document-level permissions?

Not by itself. An API key may identify a client or scoped principal and participate in an authorization policy, but it does not automatically reproduce source document permissions for the requesting end user. Verify the identity mapping, policy enforcement and permission-update behavior for the specific connector.

Should disabling a user delete the documents they created or accessed?

No. Disabling a user should revoke that principal's access while preserving shared documents for other authorized users according to ownership and retention policies.

Is verifying search results sufficient to validate connector security?

No. Security acceptance requires testing direct document requests, preview downloads, vector context chunks, agent tool responses, result counts, and cross-user cache boundaries.