AIEGIS EYE

AIEGIS EYE is the endpoint-side half of the AIEGIS harness. A sensor on every laptop captures which AI vendors the user contacts (ChatGPT, Claude, Copilot, Gemini, Cursor, Cohere, Mistral, Perplexity, Codeium, Windsurf) at the network layer, on-device. Metadata — vendor, process, user, timestamp — not prompt content, so legal and works councils approve deployment.

The visibility gap

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 EYE closes the gap. Every connection from a deployed endpoint to ChatGPT, Claude, Copilot, Gemini, Cursor — logged and visible on your own infrastructure. Process, user, vendor, timestamp.

How it works

Endpoint sensor (Rust core). One signed binary per OS. Runs as a Windows service / macOS LaunchDaemon / systemd unit. Source-complete with 10 vendor signatures. Detects when an AI vendor is contacted at the network layer, on-device. Logs which vendor, which process, which user, when. Metadata, not content.

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 collector. AIEGIS LIMITED never sees your data.

How to start

1. Quick chat. We confirm fit — you operate in the EU, use AI tools, have a CISO or compliance officer.
2. 30-day free pilot. We install on 10–50 endpoints. Your team operates the dashboard. We support.
3. Contract. By-contact pricing tailored to your fleet size. No hidden fees. Design-partner contracts before August 2026 lock pricing for 24 months.

Talk to us about a pilot

Detection layers

Eye correlates three signals to identify a vendor connection without ever decrypting payload.

• TLS socket scan — cross-platform. Linux: /proc/net/tcp + /proc/net/tcp6 walked every 5 seconds with inode→process attribution. macOS: lsof -nP -iTCP:443 -sTCP:ESTABLISHED. Windows: GetExtendedTcpTable with TCP_TABLE_OWNER_PID_ALL.
• Process enumeration — matches running binaries against the vendor process-hint table (chatgpt.exe, cursor.exe, claude.exe, etc.).
• Vendor-IP table — forward-resolves every entry in vendors.domains hourly into an in-memory IP set. Each established peer IP looks up in O(1). Catches Cloudflare-fronted vendor APIs that defeat reverse-DNS attribution.

Shadow AI detection patterns

Shadow AI is the unsanctioned, unlogged, unbudgeted use of generative AI tools by employees outside the procurement perimeter. 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.

• 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.
• 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.
• 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.

Browser extension & native messaging host

The browser extension 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, and a background service worker that talks to a local native messaging host over stdin/stdout.

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 exchange JSON with a single host binary registered against an extension ID. The host binary — AIEGIS EYE Helper — is the only on-device process holding the audit-log signing key.

Data flow, end to end.

• Capture. Content script observes the prompt-box submit event. The raw prompt 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: redacted prompt + redaction-receipt (count of fields stripped, classes hit).
• Block / warn / allow. The redactor returns a decision. Block: submit cancelled in the page, in-line policy message shown. Warn: interstitial. Allow: submit proceeds unchanged.
• Signed event. Decision plus redaction-receipt forwarded to the helper. Helper signs with the endpoint's enrolment key and POSTs to your collector. AIEGIS staff never see the event.

How Eye differs from a DLP tool

Traditional Data Loss Prevention tools were built for the email and file-share era. They classify content at rest, inspect attachments, 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; 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 installs on personal devices.
• DLP scales by content patterns; Eye scales by vendor signatures. Adding a new vendor is a single signature row (host suffix, expected ALPN, expected JA3). Adding a new content rule to DLP is a regex change with 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 for EU AI Act Article 12 audit retention, not 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.

POST /api/eye/activate

Called once per device on first launch. Exchanges a license key + machine fingerprint for a device_id and device_secret. The secret is the HMAC key used to sign every subsequent event batch and heartbeat.

curl -X POST https://YOUR-COLLECTOR/api/eye/activate \
  -H "Content-Type: application/json" \
  -d '{
    "license_key": "AKEY-XXXX-XXXX-XXXX-XXXX",
    "tenant_id": "your-tenant",
    "machine_fingerprint": "host-uuid-here",
    "hostname": "alice-laptop",
    "os": "windows-x86_64",
    "sensor_version": "0.1.0"
  }'

Returns: {"device_id": "dev-…", "device_secret": "…"}. Re-activation of the same fingerprint is idempotent — returns the existing secret.

POST /api/eye/events

Sensor posts batched, HMAC-signed event envelopes. Max 1024 events per batch. Each envelope: {"event": <EyeEvent>, "signature": <hex-sha256-hmac>}. Server re-computes HMAC against devices.device_secret; mismatch rejects that envelope (the rest of the batch still applies).

POST /api/eye/events
{
  "schema_version": 1,
  "events": [
    {
      "event": { "event_id": "...", "device_id": "dev-...",
                 "tenant_id": "...", "observed_at": "2026-06-09T13:06:55Z",
                 "vendor_id": "openai", "detection_layer": "dns",
                 "host": "api.openai.com", "process_name": "chrome.exe",
                 "user": "alice", "sensor_version": "0.1.0",
                 "schema_version": 1 },
      "signature": "..."
    }
  ]
}

Returns: {"accepted": N, "rejected": M}. Successful batches bump devices.last_seen_at.

POST /api/eye/heartbeat

Explicit liveness ping fired every 60s even when zero vendor activity. Lets the dashboard show "Last seen" within seconds of install on low-AI-usage endpoints.

POST /api/eye/heartbeat
{
  "device_id": "dev-...",
  "observed_at": "2026-06-09T13:30:10Z",
  "signature": "..."
}

Canonical bytes for HMAC: "AIEGIS_EYE_HEARTBEAT_V1\0" + device_id + "|" + observed_at. Bumps last_seen_at; returns {"ok": true}.

GET /api/eye/status?device_id=…

Public read endpoint. Returns device metadata + 20 most recent events for one device. Used by the dashboard look-up flow and smoke tests.

{
  "device_id": "dev-ac86efd7ac8d3b59e8a671ca",
  "tenant_id": "aiegis-test",
  "hostname": "unknown",
  "os": "linux-x86_64",
  "sensor_version": "0.1.0",
  "activated_at": "2026-06-06 23:26:24",
  "last_seen_at": "2026-06-09 13:30:10",
  "event_count": 2,
  "recent_events": [...]
}

GET /api/eye/summary?tenant_id=…

Tenant-wide rollup. Returns device count, 24-hour vendor mix, total events, and 50 most recent events for the whole tenant. Powers the dashboard tenant view.

GET /api/eye/alerts?tenant_id=…

Computed alert feed. Three classes fire today:

• sensor_stale — last_seen_at > 5min: warn; > 30min: high.
• new_vendor_detected — a vendor first observed in the last 24h. info.
• vendor_spike — 24h event count > 3× the 6-day baseline daily average AND > 10 events. warn.

Returns: {"tenant_id":"…","alerts":[…],"alert_count":N}.

GET /api/eye/report.csv?tenant_id=…&since=…&until=…

Tenant-scoped event export as RFC-4180 CSV. Columns: received_at, device_id, vendor_id, detection_layer, host, process_name, user_acct, sensor_version. Optional since and until ISO-8601 datetime filters.

Response sets Content-Disposition: attachment so the dashboard's "Download CSV" button drops a file straight to disk.

GET /api/eye/report.json?tenant_id=…&since=…&until=…

Same shape as the CSV endpoint, JSON envelope. Returns {tenant_id, since, until, event_count, events:[…]}. Suitable for downstream ingest into a SIEM or BI tool.

Vendor signature table

10 canonical vendors locked at v0.1.0 (2026-06-06).

Event schema

Every EyeEvent is metadata-only. The Rust core, the SQL schema, and the API model are all aligned — adding a payload column would break the brand promise on aiegis.ie/aiegis-eye and the contract with the customer's works council.

EyeEvent {
  event_id:        Uuid,           // v4, globally unique
  device_id:       String,         // dev-...
  tenant_id:       String,
  observed_at:     DateTime<Utc>,  // when on-endpoint
  vendor_id:       String,         // see vendor table
  detection_layer: "dns" | "tls_sni" | "process" | "browser_extension",
  host:            String,         // canonical vendor domain
  process_name:    Option<String>, // e.g. "chrome.exe"
  user:            Option<String>, // DOMAIN\username
  sensor_version:  String,
  schema_version:  u32,
}

HMAC signing

Every event and every heartbeat is HMAC-SHA256 signed by the sensor using device_secret. The server re-computes and compares with hmac.compare_digest.

Event signing. Canonical bytes = stable, sorted JSON of the envelope (no whitespace, sorted keys, recursive). Implementation in src/events.rs:

impl EyeEvent {
  pub fn sign(&self, secret: &[u8]) -> String {
    let mut mac = Hmac::<Sha256>::new_from_slice(secret).unwrap();
    mac.update(&self.canonical_bytes());
    hex::encode(mac.finalize().into_bytes())
  }
}

Heartbeat signing. Canonical bytes = "AIEGIS_EYE_HEARTBEAT_V1\0" + device_id + "|" + observed_at. The domain-separation tag prevents cross-context signature reuse.

OS support matrix

EU AI Act Article 26 evidence-ready

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.

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.

5-year retention is enforced at the database trigger layer, not the application layer. A misconfigured retention policy cannot delete an audit row before the Article 12 floor.

GDPR Articles 13 & 14 employer transparency

Any tool that observes employee behaviour on a corporate device sits inside the GDPR transparency obligations of Articles 13 and 14. Eye is engineered to make employer compliance a configuration exercise, not a legal redesign.

• Article 13 notice surface. The browser extension exposes an "About AIEGIS EYE on this device" page listing data categories captured, lawful basis (Article 6(1)(f) legitimate interest), retention period (configurable, default 13 months), and 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.
• Employee subject-access export. Built-in /me endpoint on the self-hosted collector returns the full set of Eye events for a single employee on request, as a signed JSON bundle — works council friendly, audit-defensible.

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.

DORA, NIS2, AIVSS

Eye is a sensor designed against the specific regulatory geometry of the EU AI Act, the Irish Data Protection Act 2018, DORA for financial entities, and NIS2 Directive transposition deadlines.

• 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 mapping into the AIVSS time-to-enforce score for the affected agent. The race-test fixture co-authored by AIEGIS (commit 9c72ca06) exercises this dimension at the audit-pack-signing layer.

OWASP AIVSS co-author, not citation

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.

Install (Windows)

1. Download the signed MSI from your customer portal (or pilot link).
2. Run msiexec /i AiegisEye.msi LICENSE_KEY=AKEY-XXXX-XXXX-XXXX-XXXX TENANT=your-tenant /qn from an elevated prompt.
3. Service NT SERVICE\AegisEye registers and starts. First heartbeat lands in your collector within 60 seconds.
4. Group Policy templates (ADMX) ship in the MSI — drop them in your Central Store to enforce license + collector URL fleet-wide.

Install (macOS)

1. Download the notarised PKG.
2. sudo installer -pkg AiegisEye.pkg -target / — installs /usr/local/bin/aiegis-eye and the launchd LaunchDaemon at /Library/LaunchDaemons/ie.aiegis.eye.plist.
3. Drop your license key at /var/lib/aiegis-eye/config.json or set via MDM profile (Jamf, Kandji, Mosyle, Intune-for-Mac).
4. Restart the daemon: sudo launchctl kickstart -k system/ie.aiegis.eye.

Install (Linux)

1. DEB on Ubuntu/Debian: sudo dpkg -i aiegis-eye_0.1.0_amd64.deb. RPM on RHEL/Fedora: sudo dnf install aiegis-eye-0.1.0-1.x86_64.rpm.
2. Edit /var/lib/aiegis-eye/config.json with your license key + tenant.
3. sudo systemctl enable --now aiegis-eye.service.
4. Verify: journalctl -u aiegis-eye -n 20 shows vendor-IP table refreshed: N IPs covering 10 vendors.

Uninstall

• Windows: msiexec /x AiegisEye.msi /qn.
• macOS: sudo /usr/local/bin/aiegis-eye-uninstall — removes the daemon plist, binary, and per-user agent.
• Linux (DEB): sudo apt remove aiegis-eye. (RPM): sudo dnf remove aiegis-eye.

Activated devices remain in the collector's devices table for audit. Revoke a license seat from the dashboard if you want to free the seat for re-use.

Dashboard · Look up a device or tenant

Open aiegis-eye-dashboard. Enter a device_id (starts with dev-) for the single-device view, or a tenant_id for the tenant rollup.

The page auto-refreshes every 30 seconds. URL is shareable — ?id=… seeds the lookup, so you can drop a dashboard link into a Slack channel and the recipient lands on the right view.

Dashboard · Alerts

Each lookup pulls /api/eye/alerts and renders coloured banners above the events table:

• High — sensor silent > 30 minutes.
• Warn — sensor silent > 5 minutes, or vendor spike (>3× baseline).
• Info — new vendor first seen for this tenant in 24h.

External delivery channels (email, Slack, SMS) are a separate workstream — see roadmap.

Dashboard · Reports CSV / JSON

The "Download CSV" and "Download JSON" buttons on the tenant view call /api/eye/report.csv and /api/eye/report.json respectively, scoped to the current tenant. Pass since and until via URL query to restrict the window.

The CSV is RFC-4180 compliant: header row, quoted fields containing commas or newlines, double-quote escape for embedded quotes. Drops straight into Excel, Google Sheets, or any BI tool.

Frequently asked questions

What does AIEGIS EYE do?

An endpoint sensor that detects when employees connect to AI vendors (ChatGPT, Claude, Copilot, Gemini, Cursor, Cohere, Mistral, Perplexity, Codeium, Windsurf) at the network layer, on-device. Metadata only — not prompt content — so legal and works councils approve deployment.

Is AIEGIS EYE live in production today?

The Linux sensor + backend ingest + dashboard + alerts + reports are LIVE on aiegis.ie today (proven end-to-end on this VPS). Windows MSI and macOS PKG are source-complete; signed builds gated on Apple Developer cert + Authenticode EV. Design-partner pilots in progress.

How does Eye help with EU AI Act Article 26 compliance?

Article 26 requires deployers to log agent activity, identify operators, and prove human oversight. Eye provides the agent-activity log (which vendor, which process, which user, when), signed via the AIEGIS audit trail. Penalties for non-compliance up to 7% global revenue.

What data does Eye send back to AIEGIS?

None. Self-hosted by default — events stay on customer infrastructure. The managed tier ships single-tenant SaaS in your own VPC; AIEGIS staff never touch your data.

What about AIVSS scoring?

AIEGIS co-authored OWASP AIVSS Issues #31 (Runtime Enforcement Effectiveness) and #32 (Multi-Agent Governance Gaps). Eye events feed the AIVSS scoring pipeline.