When employees use ChatGPT, Claude, or Gemini at work, your CISO has no idea what data walks out the door. Current enterprise AI visibility is near-zero.

• 68% of organisations cannot distinguish AI agent activity from human activity (CSA + Aembit, March 2026).
• 99% of attack attempts originate from authenticated sources — rogue agents with legitimate credentials (Salt Security, 1H 2026).
• Cloud-only competitors send your logs to American servers. You forfeit EU data residency and compliance.

aiegis closes that gap. Every connection from a deployed endpoint to ChatGPT, Claude, Copilot, Gemini, Cursor — logged and visible on your own infrastructure. Process, user, vendor, timestamp.

Endpoint sensor (v0.5, Windows). Designed to run on every employee laptop. Source-complete (Rust, 10 vendor signatures); MSI installer pre-customer state. Detects when an AI vendor (ChatGPT, Claude, Copilot, Gemini, Cursor) is contacted — at the network layer, on-device. Logs which vendor, which process, which user, when. Metadata, not content — built so legal and works councils approve deployment.

In practice. Your sales lead opens ChatGPT in a browser. aiegis records the connection, the user, the workstation, the timestamp. Your CISO gets a daily report: which teams use which AI tools, how often, on what devices. Evidence-grade, audit-ready.

Nothing reaches us. Logs go directly from endpoint to your cloud. aiegis Ltd never sees your data.

Roadmap (v0.6, in build). Browser-extension-based prompt blocking on Chrome, Edge, Safari, Firefox — block prompts containing customer data, source code, PII before they leave the browser. v0.7: Windows native desktop apps + CLI tools (ChatGPT.app, Claude.app, claude CLI, aider, Cursor) via TLS proxy with corporate CA. Mac native apps logged for audit (cert pinning prevents block). All on the same v0.5 sensor backbone.

Articles 12 (audit retention, 5-year floor) and 26 (human oversight) enforced today via signed reason codes returned by /api/protect + the documented Article 26 walkthrough. Hard deadline for high-risk obligations under Articles 9–17 + 26: August 2026 for new deployments; August 2027 legacy-transition for systems already on market. Penalties up to 7% of global revenue.

aiegis gives you a complete, cryptographically-signed audit trail stored in your own infrastructure — not ours.

aiegis authored the audit-pack-signing v0.5 race-test fixture merged into OWASP's AIVSS enforcement-effectiveness working text on 2026-05-09 (commit 9c72ca06). The fixture spec.md sha-256 c5f62c9fce6e08b55dab6dfbc8caa0196af61db1eddd0046b43dfa21c9261f28 is byte-for-byte cited in the OWASP working text. We participate in the AIVSS Issue #31 enforcement-effectiveness dimension working group on the 2026-05-15 review cadence.

For procurement: when you ask "is your audit trail cryptographically defensible?", the answer is "we wrote the OWASP fixture that defines defensible." Not a vendor claim — a public artifact at github.com/aeoess/aivss-enforcement-effectiveness with verifiable sha.

Quick chat. We confirm fit — you operate in the EU, use AI tools, have a CISO or compliance officer.

30-day free pilot. We install on 10–50 endpoints. Your team operates the dashboard. We support.

Contract. By-contact pricing tailored to your fleet size. No hidden fees. Design-partner contracts before August 2026 lock pricing for 24 months.

Get started

Shadow AI is the unsanctioned, unlogged, unbudgeted use of generative AI tools by employees outside the procurement perimeter. It is the dominant AI risk class in 2026 enterprises — not because employees are malicious, but because every browser tab is now a potential data-exfiltration channel into a third-party model provider. aiegis Eye is built specifically to surface that traffic.

Three detection layers, every endpoint. Eye correlates DNS resolution, SNI inspection, and process attribution to identify a vendor connection without ever decrypting payload. A connection to chat.openai.com from chrome.exe running under user alice@corp at 14:02:11 is one row. A connection to api.anthropic.com from cursor.exe from the same user is another. The row, not the prompt, is the evidence unit.

• Sanctioned vs shadow. Eye reconciles every connection against your IT-approved AI vendor allowlist. Anything outside the allowlist is a shadow event. The dashboard ranks shadow events by frequency, by user, by department, by data-classification proximity.
• Account-mode signal. When a vendor exposes account-tier hints in the TLS handshake (free, plus, team, enterprise), Eye records the tier. A personal ChatGPT Plus account used on a corporate laptop is a different risk than a corporate ChatGPT Enterprise tenant — Eye surfaces the difference.
• Burst-pattern detection. A normal knowledge-worker emits 30–150 AI vendor connections per day. A 600-connection burst inside 20 minutes correlates with paste-loops, scraping behaviours, or automated agent runs on the endpoint. Eye flags the burst, not the user.
• Cross-device fingerprinting. A single Microsoft Entra ID seen connecting from both a managed laptop and an unmanaged personal device to the same vendor account is a BYOD shadow-AI signal — one of the highest-yield enforcement triggers in 2026 EU works-council reviews.

Every signal is a row in your own database. Eye never aggregates across customers, never trains on your traffic, never sees your endpoint telemetry on aiegis infrastructure.

The v0.6 browser extension is the active customer-facing surface today. It runs on Chrome, Edge, Brave and (signed builds) Firefox. The extension is intentionally thin — a content script that observes the DOM of supported AI vendor sites (ChatGPT, Claude, Copilot, Gemini), and a background service worker that talks to a local native messaging host over a stdin/stdout pipe.

Why native messaging. Browser extensions cannot, by Chrome's security model, write to disk, open arbitrary sockets, or sign payloads with a system key. They can, however, exchange JSON with a single host binary registered against an extension ID. That host binary — aiegis Eye Helper — is the only on-device process holding the audit-log signing key. Prompts redacted in the browser, signed by the helper, posted to your self-hosted collector. The browser never sees the signing key; the helper never reaches the network without a signed receipt.

Data flow, end to end.

• Capture. Content script observes the prompt-box submit event. The raw prompt text never leaves the page.
• Redact-in-browser. A WASM module runs the configured redaction policy (PII, secrets, code-fence allowlists) on the raw prompt. Output is a redacted prompt + a redaction-receipt (count of fields stripped, classes hit).
• Block / warn / allow. The redactor returns a decision. If block, the submit event is cancelled in the page; the user sees an in-line policy message. If warn, the user gets an interstitial. If allow, the submit proceeds unchanged.
• Signed event. The decision plus the redaction-receipt (not the prompt content) is forwarded to the helper. The helper signs with the endpoint's enrolment key and POSTs to your collector. The collector is yours; aiegis staff never see the event.

Redaction-in-browser proof. The WASM redactor is open source under the same audit-pack-signing scheme as the OWASP AIVSS fixture — you can shasum it and pin the version in your endpoint policy. Customers in regulated sectors run the redactor offline, sha-pin the WASM, and treat any drift from the pinned hash as a Sev-1 incident. The redactor is not a cloud service. It is a 240KB module bundled with the extension.

The first question every CISO asks: "we already have a DLP — why do I need Eye?" The answer is that traditional Data Loss Prevention tools were built for the email and file-share era. They classify content at rest, inspect attachments, and gate egress at the network perimeter. None of those primitives map cleanly to a browser tab paste-bar talking TLS 1.3 to an AI vendor.

• DLP inspects content; Eye inspects context. A DLP sees "the word PROJECT-X appears in the buffer". Eye sees "user alice is pasting into chat.openai.com from a managed laptop at 23:14 outside her normal pattern". Both signals matter; only Eye produces the latter on-device, without breaking TLS.
• DLP requires MITM TLS interception to see prompts; Eye does not. Eye redacts in-browser before submit, so the prompt is gated inside the application's TLS session. No corporate CA pinning, no certificate-authority installs on personal devices, no helpdesk tickets when Cursor or Claude.app reject MITM certs.
• DLP scales by content patterns; Eye scales by vendor signatures. Adding a new AI vendor to Eye is a single signature row (host suffix, expected ALPN, expected JA3 fingerprint). Adding a new content rule to DLP is a regex change with an enterprise-wide rollout cost.
• DLP produces case files; Eye produces audit ledger entries. Each Eye decision is a signed row referencing a policy version, a redactor hash, and an endpoint enrolment ID — structured exactly for EU AI Act Article 12 audit retention, not for DLP-style incident review.

Eye does not replace DLP. It sits beside DLP and covers the surface DLP was never designed for: the post-TLS, pre-vendor prompt window inside the browser.

Any tool that observes employee behaviour on a corporate device sits inside the GDPR transparency obligations of Articles 13 (information to be provided where personal data are collected from the data subject) and 14 (where data are obtained from another source). Eye is engineered to make employer compliance with both articles a configuration exercise, not a legal redesign.

Three transparency primitives, on by default.

• Article 13 notice surface. The browser extension exposes an "About aiegis Eye on this device" page accessible from the extension icon. It lists the data categories captured (vendor host, process name, redacted prompt receipts), the lawful basis (Article 6(1)(f) legitimate interest, with the DPIA template aiegis publishes at /dpia), the retention period (configurable, default 13 months), and the data controller (your organisation, not aiegis).
• Article 14 disclosure for ingested telemetry. Where Eye correlates an endpoint enrolment with HR identity systems, the joining table is named and the source is logged. That join is the high-risk surface; Eye logs every read of it.
• Employee subject-access export. A built-in /me endpoint on the self-hosted collector returns the full set of Eye events for a single employee on request. The export is a signed JSON bundle — works council friendly, audit-defensible.

None of this is bolt-on. Eye ships with the works-council templates — in English, German, French, Spanish, Dutch — co-signed against the GDPR Article 88 employment-context derogations live in each EU member state.

Eye is engineered for heterogeneous fleets. The browser extension is the cross-platform surface; the desktop sensor and helper components vary by OS to use the right primitive on each platform.

• Windows. MSI installer, signed with the aiegis code-signing certificate. Sensor runs as a Windows service under NT SERVICE\AegisEye; helper runs per-user. Group Policy templates ship in the same MSI. Tested on Windows 10 22H2, Windows 11 23H2/24H2, and Windows Server 2022 RDS hosts.
• macOS. Notarised PKG installer. Sensor runs as a launchd LaunchDaemon; helper as a per-user LaunchAgent. The browser extension carries the bulk of the prompt-monitoring weight on macOS because native AI desktop apps (Claude.app, ChatGPT.app) pin their own certificates — Eye logs the connection for audit but does not break TLS. MDM profiles available for Jamf, Kandji, Mosyle, Intune-for-Mac.
• Linux. DEB and RPM packages for Ubuntu LTS 22.04 / 24.04, Debian 12, RHEL 9, Fedora Workstation. systemd unit for the sensor; user-systemd for the helper. Selected for build farms, developer-workstation fleets, and CI runners where Cursor, aider, and the claude CLI run.

Cross-platform parity is enforced by a single Rust core (the sensor) and a single Manifest V3 extension bundle (the browser surface). The platform-specific wrappers are thin and auditable.

Eye is not a general endpoint sensor that happens to mention AI. It is a sensor designed against the specific regulatory geometry of the EU AI Act, the Irish Data Protection Act 2018, the upcoming Digital Operational Resilience Act (DORA) for financial entities, and the NIS2 Directive transposition deadlines.

• EU AI Act Article 26 (deployers of high-risk AI systems). Eye produces the agent-activity log named in Article 26(5) — vendor identity, operating context, user attribution, timestamp, retention. The Article 26 walkthrough at /article-26-walkthrough maps each obligation to a specific Eye event field.
• EU AI Act Article 12 (record-keeping). Eye events ship with a 5-year retention floor enforced at the database trigger layer, not at the application layer. A misconfigured retention policy cannot delete an audit row before the Article 12 floor.
• DORA ICT third-party risk register. Every AI vendor a financial-services employee touches is, under DORA, an ICT third party. Eye exports a vendor frequency report directly into the DORA register template — closing the gap between procurement-known vendors and actually-used vendors.
• NIS2 Article 21 supply-chain measures. Critical and important entities under NIS2 must monitor third-party software in use. Eye treats every AI vendor as a third-party software dependency and feeds the vendor map into the NIS2 supply-chain inventory.
• OWASP AIVSS — enforcement-effectiveness dimension. Each Eye decision carries a decision_ms field that maps directly into the AIVSS time-to-enforce score for the affected agent. The AIVSS race-test fixture co-authored by aiegis (commit 9c72ca06) exercises this dimension at the audit-pack-signing layer.

Each use case is configured, not coded. The same sensor, the same extension, the same helper — different report templates and retention shapes per regulation. One install, every applicable EU regulation served.