Least privilege
Each source and provider receives only the capabilities and authority appropriate to its role.
Hexjack Lens · Secure by Design
Secure by Design. From the first decision.
Secure by Design isn't a final hardening phase for Hexjack Lens. It's a constraint on the entire product.
Why it matters
Lens sits at an important boundary.
Hexjack Lens provides AI systems with controlled access to organisational information and may use credentials capable of reaching high-value systems. Security therefore belongs in the architecture itself.
Material capabilities are considered in terms of the trust boundaries, authority, data flows, failure modes and abuse cases they introduce.
Secret isolation
Lens resolves logical credential references at runtime. Secret values remain separate from non-secret topology and are not exposed through normal MCP discovery or diagnostics.
Bounded interfaces
The common source contract is destination-bound and capability-aware: callers research configured sources rather than choosing arbitrary hosts or generic request primitives.
Untrusted content
Retrieved information is classified as untrusted evidence. Its contents cannot grant additional Lens authority or become trusted control instructions.
Controlled deployment
The supported OCI/native baseline keeps configuration and credentials external, runs the reference OCI deployment non-root with a read-only root filesystem and explicit writable cache state, and proves local readiness without a Digital Unity callback. Lens derives approved remote destinations from topology and rejects unconfigured HTTP targets; customer firewall/proxy enforcement remains an independent deployment control.
Verifiable releases
The controlled release workflow connects software inventory, vulnerability evidence, signatures and provenance to exact artifacts, with a defined customer verification path for OCI and native distributions.
Maintained threat model
The threat model moves with the product.
Lens has an implementation-coupled threat model covering the MCP boundary, runtime configuration and credentials, configured information sources, local repository persistence, delegated investigation transport and the software supply chain. Material security changes review that model and either update the affected threats and controls or record why the existing model already covers the change.
Repository controls
Local Git access is constrained before content is read.
Where local mirror-backed retrieval is enabled, repository access is bound to configured source aliases and private bare mirrors beneath a trusted cache root. Direct provider retrieval remains a separate path and does not require a local repository copy. Lens validates containment, rejects nested symlinks and special files, verifies the configured remote identity and records refresh freshness only after successful fetches.
Git runs with fixed argument vectors, no shell, disabled hooks and text conversion, restricted protocols and runtime-only credentials. Repository content, including symlinks and search results, remains untrusted evidence and cannot expand Lens authority. Mirror lifecycle is internal cache management rather than a public synchronisation capability, and delegated investigation does not require a Lens mirror.
Fail closed
Invalid input must not widen authority.
Configured identities, runtime credential resolution and source/investigation capability boundaries are designed to fail without falling back to broader destinations, alternate credentials or additional capability. Investigation endpoints are selected only from trusted configuration, redirects are rejected, and provider failures are normalised rather than passing upstream bodies or sensitive routing detail through verbatim.
Research and delegated investigation are bounded by explicit input, output and timeout limits. The application derives and enforces its approved HTTP destination set and can report that set to operators, while customer firewall, proxy or CNI policy remains the independent process-level containment layer.
Operational security
Useful diagnostics without creating another sensitive-data store.
Lens keeps operational audit metadata-only: operation identity, bounded correlation, outcome, duration and timestamp can be recorded without request text, retrieved content, credentials, private endpoints or local paths. Runtime work is finite and cancellation-aware, 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. Runtime credentials can be rotated or rolled back outside the application artifact without changing the public research topology.
The principle
Security evidence should come from controls that shaped the product.
It should not be assembled afterwards to make an already-designed system appear Secure by Design. Security requirements influence architecture; architecture constrains implementation; implementation is verified across the assembled product surface; release evidence and customer verification then describe the exact artifact that resulted.
Supply chain
Security starts before the container starts.
Dependencies, build inputs and release provenance matter alongside runtime controls. Lens has a controlled release workflow with software inventory, vulnerability assessment, exact artifact identity, keyless signing and build provenance. Ordinary PR CI verifies tests, source vulnerabilities/secrets, native builds, OCI builds and the built OCI image itself, while cross-cutting security verification keeps the public tool boundary, destination controls, secret safety, hostile-content handling, traversal limits and runtime assumptions tied to executable evidence.
Software assurance →