Hexjack Lens · How it works

One controlled research layer across the information estate.

Lens gives authorised AI clients a stable way to discover and research configured organisational sources without exposing every provider API, credential or execution environment directly.

Research contexts

Named contexts group the sources belonging to a product, project or organisation. AI clients can discover safe source identities and capabilities without receiving private credential material.

Bounded operations

Sources advertise search, retrieve and optional investigate capabilities, while trusted runtime policy determines the authority actually available.

Configured destinations

The common source boundary is constructed around configured destinations. Caller requests do not contain arbitrary host, workspace, root or generic request selectors.

Contexts, not credentials

Configure the estate once.

Lens separates non-secret topology from runtime credentials. A research context can describe which approved sources belong together and what each source supports while credentials are referenced by logical identity and resolved privately at the point of use.

Different sources can use independent credential profiles, and credential material can be rotated without rebuilding the application artifact or changing the public research topology.

Retrieve

Find what the organisation already knows.

Retrieval searches and reads existing information from authorised sources. It is intentionally bounded: the caller selects configured contexts and sources rather than arbitrary hosts, filesystems or network destinations.

The common adapter contract applies provider-neutral request and evidence bounds, normalised failure semantics and minimum provenance. Concrete source adapters then implement their own upstream behaviour within that boundary.

Atlassian

Jira and Confluence through one controlled source boundary.

The Atlassian source provides explicit read-only MCP operations for configured sites: list approved site aliases, search Jira with JQL, read an issue, search Confluence with CQL and read a page.

Requests route through configured site aliases rather than caller-supplied hosts. Searches and page/issue reads are bounded, pagination state is preserved, upstream failures are normalised and returned content carries source identity and provenance as untrusted evidence.

The public surface deliberately contains no create, update, delete, transition or generic HTTP/request primitive.

Bitbucket

Repository metadata without giving AI repository authority.

The Bitbucket source can list configured workspaces and repositories, read pull-request metadata and bounded diffs, and list and read commits through approved repository identities.

Collections and diffs are bounded, pagination and truncation are explicit, provider failures are normalised and repository content remains untrusted evidence. The adapter exposes no push, merge, commit, mutation or generic upstream request capability.

Hosted provider search is the fast direct-retrieval path and requires no local repository copy. Deployments that need deterministic file-at-ref reads or repeated literal code/text search can additionally enable Lens's private local Git-mirror retrieval capability.

Repository mirrors

Read source at an immutable commit, locally and predictably.

repository.get_file and repository.search_code operate only on bare Git mirrors derived from configured source aliases. Callers cannot supply a repository URL, workspace, filesystem root or mirror path.

Each request resolves the requested branch, tag or commit to an immutable commit before reading. Results carry the configured source, requested ref, resolved commit and last-successful-refresh information, so a local snapshot is never silently described as current upstream state.

Local mirrors are optional retrieval infrastructure, not Lens's general synchronisation model and not a prerequisite for investigation. Mirror lifecycle stays internal and absent from the MCP tool surface. The mirror path is contained beneath the Lens cache root, unsafe filesystem indirections fail closed, credentials are runtime-only and Git is invoked without shell or repository-controlled execution.

Documents

Bounded document access without exposing the filesystem.

Configured document-source aliases bind to operator-controlled roots. AI callers can search and retrieve through those aliases without supplying an arbitrary host, filesystem root or network path.

The reference local-filesystem adapter rejects traversal, hidden paths and symlinks, keeps reads and search results bounded, treats binary or oversized files as metadata-only evidence where appropriate and preserves source provenance as untrusted evidence. Provider-specific enterprise document systems remain separate adapters rather than being hidden behind generic filesystem access.

Investigate

Establish new findings when retrieval is not enough.

Some questions require more than search: following code paths, testing hypotheses or examining an authorised environment. Lens uses a provider-neutral Analysis Engine Contract that carries bounded questions, configured context and source scope, correlation metadata and common evidence without exposing generic shell, SQL, container or provider-orchestration primitives.

That semantic contract is paired with authenticated destination-bound transport over verified HTTPS or a configured local Unix socket and is exposed through the public research.investigate MCP operation. Endpoints and credentials come from trusted configuration rather than caller input. The analysis provider can be a remote service such as an organisation's analysis platform or a local compatible agent, and it can own its own authorised checkout, runtime or tooling. Lens returns bounded evidence-backed findings without exposing that provider's execution authority to the MCP caller.

Operational controls

Bounded research stays bounded in production.

Lens records metadata-only operational audit events without request text, retrieved content, credentials, private endpoints or local paths. Runtime work is protected by finite concurrency and cancellation-aware limits, while deployment platforms retain independent CPU, memory, storage and log-retention controls.

Optional repository mirrors are treated as disposable source-data caches with explicit protection, backup and deletion guidance. Credentials can be rotated outside the application artifact, and diagnostic commands validate configuration, readiness, version and approved network destinations without exposing secret values.

Assembled-product verification

One product boundary, exercised across independent research contexts.

The Lens acceptance gate verifies standalone operation, the exact 21-tool read-only MCP contract, independent configured contexts, source isolation, provenance, delegated investigation, hostile-content handling, restricted-network startup, deployment hardening and release verification. Cross-context or unauthorised requests fail closed rather than widening scope.

Provider neutral

Same Lens. Different estates. Different analysis environments.

The product architecture separates the information-estate interface from provider implementations. Organisations can choose the systems and analysis environments appropriate to their own estate without changing the fundamental Lens contract.

Evidence survives the journey.

The common evidence model applies across retrieval and delegated investigation. It distinguishes recorded source material, direct observations and inference, preserving provenance and support relationships without turning retrieved or generated content into trusted control instructions.

Evidence & provenance →