Patent-Pending Architecture · April 2026

The trust boundary
enterprise AI still lacks

AI adoption in the enterprise is not limited by model capability. It is limited by the absence of a structurally enforced boundary between AI systems and raw sensitive data. Sentridock builds that boundary in hardware.

Request Early Access See How It Works
62%
Experimenting
23%
In Production
1/5
Have Governance
62%
Experimenting with AI agents
McKinsey 2025 — enterprises running AI pilots
23%
Actually scaling in production
McKinsey 2025 — the gap is structural, not technical
1/5
Have mature agent governance
Deloitte 2026 — yet 74% plan agentic deployment
⚡ No software to install — boundary enforced at hardware level, not inside the OS
🔒 No agent, no plugin, no SDK — nothing runs inside the host you are protecting
⬡ Zero software footprint — the boundary cannot be bypassed by the OS, AI model, or any software
The Structural Gap

Current approaches
all fall short — architecturally

API guardrails, DLP layers, agent connectors, and model safety tuning all share one fatal flaw: they operate inside the trust domain they are meant to protect.

Approach
Where Control Sits
Remaining Exposure
API Guardrails / DLP
Inside software trust domain
AI still sees raw data before policy fires
Agent / Connector Models
Assumes host + connector trust
Integrity not verified — raw data reachable
Secure Bridges
Access control layer
AI workflows depend on raw-data reachability
Model Safety Tuning
Inside the model only
Bypassed entirely by context injection
Core insight: The weakness is architectural position, not just policy quality.
How Sentridock Works

A closed loop —
six stages, one enforced boundary

The transformation happens before any software path reaches raw data. That is the only position that cannot be bypassed.

01 ——→
01 ↓
Raw Data
Screens, files, apps, sensors
02 ——→
02 ↓
Perception
Display framebuffer or HID capture
03 ↓
03 ↓
Trust Boundary
Hardware-enforced · Non-bypassable
Hardware Enforced
←— 04
04 ↓
Transform
Many-to-one irreversible sanitization
Hardware Enforced
←— 05
05 ↓
AI Reasoning
On protected abstractions only
↑ 06
06
Controlled Actuation
Governed output back to enterprise
↩ Loop closes — back to Step 01
⬡
Why hardware? Software guardrails live inside the trust domain they protect — and can be bypassed. A hardware-enforced boundary is structurally external: the transformation happens before any software path reaches raw data.
Live Scenario

See the boundary in action

A regulated enterprise knowledge worker uses an AI assistant. Watch what happens — with and without Sentridock.

Enterprise Environment
patient_records.db
PatientSarah Chen, DOB 1982-04-12
DiagnosisStage II carcinoma
SSNXXX-XX-4821
InsuranceBlueShield #7712A
PhysicianDr. M. Torres
KVM framebuffer / HID stream
No Boundary
✕
Unprotected
Raw data passes through
AI Reasoning Layer
Waiting…
User: Summarise this patient record for the care team.
▋
1Data on screen
→
2Perception capture
→
3Trust boundary
→
4AI receives…
\n
Why Sentridock

Control over conditions,
not just connections

✕ Conventional AI Stack
Connects AI to systems
  • Focuses on connecting AI to systems inside the software trust domain
  • Assumes host or connector trust — integrity not enforced
  • AI can reach raw enterprise data before any policy fires
  • Point feature or optional capability — easily bypassed
✓ Sentridock Boundary Model
Defines the conditions under which AI may operate
  • External, boundary-centric control layer — architectural position
  • Makes no trust assumptions — enforces the boundary structurally
  • AI never reaches raw data — mandatory, non-bypassable
  • Infrastructure control plane — not a feature, not optional
  • No software to install — nothing runs inside the host you are protecting
⬡
Zero Software Footprint
No agent. No plugin. No SDK. No driver. The boundary is enforced at the hardware layer — structurally outside every software path on the host. There is nothing to install, nothing to patch, and nothing that can be disabled by the system it protects.
This is where moat and enterprise relevance begin. Control over conditions — not just connections.
Early Access

We are building the trust boundary
enterprise AI still lacks

Sentridock is in early design-partner stage. We are working with regulated-industry organisations whose AI ambitions are currently constrained by trust and governance.

Confidential. No spam. We respond within 48 hours.
Path A
Seed Investor
Join as a seed investor in Sentridock Inc. Full deck and data room available under NDA.
Path B
Strategic Partner / New BU
Explore IP injection and BU formation. Founder joins as BU Head / Chief Architect.

AI boundary across the IC design flow

Seven phases where AI tools touch sensitive design data — and what the Sentridock boundary does at each stage. Toggle the boundary on/off to see the difference.

🔒

Hardware Architecture

This section contains confidential hardware architecture details.
Enter the access code to continue.

Core concept: The device sits between the engineer's workstation and display. It receives the DisplayPort video stream (seeing exactly what the engineer sees in their EDA tool), processes the screen content through the transformation boundary, communicates with the AI endpoint over its own network connection, and delivers the AI's safe response back to the workstation as HID keyboard input — the AI literally types the answer. The host sees a display passthrough and a keyboard. Zero drivers. Zero software. Works on any OS.
Architecture — Smartphone PoC (VNC over USB)
Sentridock PoC — Galaxy S24 Ultra as USB composite device (VNC client + HID keyboard)
EDA workstation
Server room
Vivado / Innovus / VCS
No physical access
Internal net
Company LAN
VNC session
Engineer's PC
Desktop / laptop
VNC client to workstation
USB connected to phone
Galaxy S24 Ultra — USB composite device (RNDIS network + HID keyboard)
USB composite — two functions on one cable
USB func 1
RNDIS/NCM network
USB tethering (reverse)
Phone gets PC's network
VNC client connects to PC
Screen capture
VNC client on phone
Sees PC desktop
incl. VNC-to-workstation
Pixel-perfect frame buffer
USB func 2
USB HID keyboard
Types AI response
back to PC as keystrokes
Same USB cable
Android app — Sentridock transformation pipeline
On-device processing — OCR, transform, AI query
Stage 1
NPU OCR
QNN SDK / 45 TOPS
Text from VNC frame
Code region detection
Stage 2
Pattern match
Regex + trie-based
Sensitive token scan
NDA marker detect
Stage 3
Substitution
Hash-based anon
Consistent mapping
Structure preserved
Data gate
Content filter
GDS/layout blocked
NPU classifier
Software-enforced
AI cloud — phone's own WiFi / 5G (bypasses company LAN)
AI egress
WiFi / 5G
Phone's own network
Independent from LAN
Safe query only
AI client
LLM API handler
Response validation
Keystroke queue
Audit log
Response path
USB HID → PC → VNC
Keystrokes → PC →
VNC → workstation
terminal / editor
VNC over USB — single cable, zero extra hardware: The engineer's PC already runs VNC to the EDA workstation. The phone plugs into the PC via USB and acts as a composite device: (1) USB network adapter (RNDIS/NCM) lets the phone's VNC client see the PC desktop (including the nested VNC to workstation), and (2) USB HID keyboard types AI responses back. Single cable. No Bluetooth pairing. No capture dongle. The PC sees a USB network adapter and a keyboard — both class-compliant.
BC-1 Control Mode: USB HID implements Control Mode — response via keyboard protocol. VNC provides the observation path without accessing the host file system. The AI query goes through the phone's WiFi/5G, bypassing the company LAN entirely. Design data never leaves the internal network — only the anonymized query reaches the cloud.
Data flow
1
Engineer connects to EDA workstation via VNC on their PC — standard IC design workflow. The smartphone is plugged into the PC via USB-C.
2
The phone acts as a USB network device and runs its own VNC client to the PC over the USB link. The phone sees the PC's entire desktop, including the VNC session to the workstation — pixel-perfect, zero wireless latency.
3
Engineer triggers AI query (tap on phone). App captures VNC frame, runs OCR on 45 TOPS NPU, pattern-matches sensitive tokens, anonymizes them, and sends the safe query to the cloud AI via phone's own WiFi/5G — never touching the company LAN.
4
AI response returns to phone. App validates output and injects as USB HID keystrokes through the same USB cable. Keystrokes arrive at PC, flow through the VNC session, and appear in the EDA workstation's terminal. Full loop: workstation → VNC → PC → USB → phone (transform + AI) → USB HID → PC → VNC → workstation.
Specifications

Hardware

PhoneSamsung Galaxy S24 Ultra
SoCSnapdragon 8 Gen 3
NPU45 TOPS (Hexagon)
USB connectionUSB-C composite device
USB function 1RNDIS/NCM network
USB function 2HID keyboard
AI networkWiFi 6E / 5G (phone)
Extra hardware$0 — USB cable only

Performance targets

VNC frame rate30 fps over USB net
OCR latency (QNN)< 15 ms per region
Pattern matching< 5 ms (CPU)
USB HID speed~1,000 chars/sec
E2E latency< 200 ms + AI roundtrip
Root requiredYes (USB gadget mode)
PC softwareVNC server (if not running)
Workstation softwareZERO (VNC exists)
Development schedule
Week 1USB composite + VNC over USB
Configure Android USB gadget mode for composite device (RNDIS + HID simultaneously). VNC client connecting to PC over USB network. Verify screen capture of PC desktop including nested VNC session.
USB composite setupVNC-over-USB client
Week 2OCR + pattern engine
QNN SDK NPU-accelerated OCR on VNC frames. Regex + trie pattern matching for sensitive tokens. Hash-based substitution with consistent session mapping.
QNN OCR pipelinePattern + substitution engine
Week 3USB HID injection + AI client
USB HID keystroke injection through composite device. AI cloud API client over phone WiFi/5G. End-to-end: VNC capture → OCR → transform → AI → USB HID → PC → VNC → workstation.
USB HID workingE2E loop verified
Week 4Audit log + demo polish
Audit log with before/after diff. Rule config UI. Demo: engineer VNCs to Vivado with USB4 PHY RTL, triggers AI, phone captures screen, anonymizes, queries AI, types response into VNC terminal.
Audit log UIDemo-ready
4 wks
Time to working PoC
$0
Extra hardware
1 cable
USB-C — that's it
Architecture — FPGA demo (DP-in / HID-out)
Sentridock FPGA demo — Zynq UltraScale+ with DP RX & USB HID TX
Workstation
Engineer's PC
DP output & USB port
Running EDA tools
FPGA programmable logic (PL) — transformation pipeline
Ingress — screen capture & recognition
DP receiver
DisplayPort RX
DP 1.4 sink
Frame buffer capture
Passthrough to monitor
Stage 1
OCR / frame analysis
Text extraction from screen
Code region detection
EDA window identification
Stage 2
CAM pattern engine
Sensitive token match
Module / signal names
NDA marker detection
Stage 3
Substitution engine
Anonymize tokens
Strip IP identifiers
Preserve structure
AXI interconnect
Egress — AI query & HID response injection
Hard gate
Output data gate
GDS / layout content
= electrically blocked
Hardware-enforced
Network TX
Ethernet / WiFi
Safe query to AI cloud
Device's own network
Not via host network
Response buffer
BRAM / URAM
AI response staging
Output validation
Keystroke queue
HID output
USB HID emulator
Keyboard / mouse device
Types AI response back
Host sees a keyboard
Display
Monitor
DP passthrough
Unaltered video
Processing system (PS) — ARM Cortex-A53
AI client
LLM API client
Sends safe query to AI endpoint
Receives response, queues for HID
Manages API keys & sessions
Policy engine
Rule management
CAM table loading
Policy config & updates
OCR model parameters
Audit logger
Transformation trail
Every transform logged
Hash-chained audit records
Compliance evidence
Management
Web dashboard
Browser-based config
Served from embedded HTTP
Accessible via device IP
Patent alignment (BC-1 Control Mode): The HID output path is the hardware implementation of Control Mode — the device actuates the host via standard HID protocol. The host workstation never runs Sentridock software. From the host's perspective, a keyboard is typing. This is the structural isolation that makes the boundary mandatory and un-bypassable.
Data flow walkthrough
1
Engineer works in Vivado / Innovus / VCS on their workstation. The DisplayPort cable runs through the Sentridock device to the monitor. The device captures the frame buffer as a DP sink while passing video through to the display — the engineer sees no difference.
2
The engineer triggers an AI query (hotkey or physical button on device). The OCR / frame analysis engine extracts text from the current screen region — Verilog code, timing reports, error logs, waveform annotations. The CAM engine scans for sensitive tokens (proprietary module names, foundry NDA markers, signal naming patterns).
3
The substitution engine anonymizes all flagged content. The output data gate enforces hard blocks — any GDS/layout imagery detected in the frame is excluded entirely. The safe, transformed query is sent to the cloud AI endpoint over the device's own independent network connection (not through the host).
4
The AI response returns to the device. The response buffer validates the output, then the USB HID emulator types the response as keyboard input into the workstation — directly into the engineer's active text editor, terminal, or EDA tool console. The host OS sees standard HID keystrokes. No driver. No software. No clipboard.
FPGA demo specifications

Hardware platform

Target FPGAZynq UltraScale+ ZCU106
PL logic cells504K LUTs
Block RAM / URAM11 Mb / 27 Mb
PS processorQuad ARM A53 @ 1.5 GHz
DP inputDP 1.4 RX (GT transceivers)
DP passthroughDP 1.4 TX to monitor
HID outputUSB 2.0 device mode (HID)
NetworkGbE (on-board)
Board cost~$1,500 USD

Performance targets

DP capture resolutionUp to 4K @ 60 Hz
OCR latency< 50 ms per region
CAM lookup< 100 ns per token
HID typing speed~1,000 chars/sec
End-to-end latency< 200 ms + AI roundtrip
Pattern capacity~64K CAM entries
Power consumption~30 W (board total)
Host software installZERO
FPGA development schedule
Month 1-2DP RX capture & HID endpoint
Implement DisplayPort 1.4 receiver using GT transceivers. Build DP TX passthrough to monitor. Frame buffer capture to BRAM/DDR. USB HID device-mode endpoint bring-up with basic keystroke injection test.
RTL: DP RX/TX pipelineRTL: USB HID endpointBoard bring-up verified
Month 3OCR engine & text extraction
Implement screen text extraction — hardware-accelerated in PL or software OCR on PS (Tesseract on ARM). Region-of-interest detection for EDA tool windows. Code region vs. GUI region classification.
OCR pipelineROI detectionAccuracy benchmark
Month 4CAM engine, substitution & data gate
TCAM-based pattern matching against extracted text. Hash-based anonymization with consistent token mapping. Hardware output gate for layout/GDS content blocking. AI API client on PS.
RTL: CAM engineRTL: substitution + gateSW: AI API client
Month 5End-to-end integration
Full loop: DP capture -> OCR -> CAM -> transform -> AI query -> response -> HID keystroke injection. Audit logging with cryptographic hash chain. Trigger mechanism (hotkey / physical button). Web management UI.
E2E integrationAudit log systemWeb dashboard
Month 6Demo units & partner outreach
Build 5 demo units. Live demo: engineer opens Vivado with USB4 PHY RTL, triggers AI assist via hotkey, device captures screen, anonymizes code, queries AI, types the response into the terminal. Demo to Egis, Aspeed, ALi, eYs3D, MediaTek.
5x demo unitsLive demo scenarioPartner feedback
6 mo
Time to demo
~$12K
Total hardware (5 units)
ZERO
Host software install
Architecture — Dedicated Sentridock SoC (DP-in / HID-out)
Sentridock SoC — purpose-built ASIC, 12/16nm, USB-C dongle form factor
Workstation
Engineer's PC
DP-over-USB-C out
+ USB HID in
Single cable
Sentridock SoC die — single USB-C dongle
DP RX PHY
DisplayPort receiver
DP 2.0 / Alt Mode
Frame buffer capture
Passthrough to monitor
Vision pipeline
Hardwired OCR + NPU
On-chip OCR accelerator
8 TOPS NPU for complex regions
EDA window classifier
TCAM block
128K-entry match
Single-cycle lookup
< 5 ns per token
Ternary pattern rules
Transform engine
Substitution + rewrite
AES-based token PRNG
Format-aware anon
Consistent mapping
On-chip NoC interconnect
Silicon gate
Hardware data gate
Fuse-programmable block list
Layout = disconnected
Tamper-evident path
Control CPU
RISC-V core
AI API client firmware
Policy engine + audit log
Secure boot + OTA
Network
WiFi 6E + BLE
Independent AI endpoint
Not via host network
Encrypted channel
HID TX
USB HID controller
Keyboard emulation
Keystroke injection
Mouse support for GUI
Secure memory bus (encrypted)
On-chip SRAM
8 MB SRAM
Frame buffer region
CAM + OCR state
Response staging
Secure storage
eFlash / OTP
OCR + NPU weights
Policy rules + FW
Secure boot keys
Crypto engine
AES-256 + SHA-3
Network encryption
Audit log integrity
Token PRNG
DP TX PHY
DP out to monitor
Passthrough video
Unaltered display
Optional OSD overlay
Display
Monitor
DP passthrough
+ optional OSD
(boundary status)
SoC specifications

Silicon

Process nodeTSMC 12nm / UMC 14nm
Estimated die size~15-20 mm²
NPU capacity8 TOPS INT8
On-chip SRAM8 MB (incl. frame buf)
TCAM entries128K
Control CPURISC-V RV64GC
DP interfaceDP 2.0 RX + TX (Alt Mode)
HID interfaceUSB 2.0 HID device
NetworkWiFi 6E + BLE 5.3

Product form factor

Form factorUSB-C dongle (~7 x 3 cm)
ConnectorsUSB-C in, DP out, USB-A HID
Power budget< 5 W (bus powered)
External DRAMOptional 256 MB LPDDR4
OCR latency< 10 ms per region
HID typing speed> 2,000 chars/sec
Target BOM cost$40-70 @ volume
Target retail price$300-500 per device
SoC development schedule
Month 1-3Architecture spec & RTL reuse
SoC architecture spec from FPGA feedback. Port FPGA RTL to ASIC (replace URAM with compiled SRAM, GT with DP PHY IP). NPU micro-architecture for on-chip OCR. DP PHY IP licensing.
SoC specASIC RTL portDP PHY IP licensed
Month 4-7RTL design & verification
NPU RTL with OCR accelerator, TCAM, crypto, DP RX/TX PHY, USB HID controller. UVM verification. Lint, CDC, formal. WiFi/BLE MAC integration.
RTL freezeUVM testbenchFormal signoff
Month 8-10Synthesis, P&R, tape-out
Synopsys DC synthesis. Innovus P&R. Timing closure across PVT. DRC/LVS. Mixed-signal integration for DP PHY. GDS tape-out.
NetlistGDS tape-outSignoff reports
Month 11-15Fabrication & bring-up
TSMC/UMC shuttle. Wafer fab (~3-4 months). BGA packaging for DP PHY SI. First silicon vs. FPGA golden reference. DP PHY characterization.
First siliconDP PHY charYield analysis
Month 16-20Validation & production
Full silicon validation. Firmware (AI client, OCR model, policy, OTA, secure boot). USB-C dongle PCB with DP connector, USB-A HID, WiFi antenna. FCC/CE/VESA certification. Production ramp.
Validated siliconProduction dongleFirst shipment
20 mo
Time to production
$3-5M
NRE (DP PHY + mask)
< 5 W
Bus-powered
Side-by-side comparison — all three phases
AttributeSmartphone PoC (Phase 0)FPGA demo (Phase 1)Dedicated SoC (Phase 2)
PurposeValidate pipeline logicCustomer demosProduction at scale
Form factorPhone + $20 dongleDev board (~15 x 15 cm)USB-C dongle (~7 x 3 cm)
InputVNC over USB (RNDIS)DisplayPort 1.4 RXDP 2.0 RX (Alt Mode)
OutputUSB HID keyboardUSB 2.0 HIDUSB 2.0 HID + mouse
DisplayN/A (VNC-based)DP 1.4 TXDP 2.0 TX + OSD
Host softwareNoneNoneNone
OCR engineQNN SDK (45 TOPS NPU)Tesseract on ARMOn-chip NPU (8 TOPS)
OCR latency< 15 ms< 50 ms< 10 ms
HID speed~1,000 chars/sec (USB)~1,000 chars/sec (USB)> 2,000 chars/sec (USB)
NetworkWiFi / 5G (phone)GbE (board)WiFi 6E + BLE
Data gateSoftware classifierFPGA fabricFuse-programmable silicon
Security modelOptional (bypassable)Inline mandatoryHardware root of trust
PowerPhone battery~30 W (PSU)< 5 W (bus)
Unit cost$0 (phone + USB cable)~$1,500$40-70 BOM
Timeline4 weeks6 months20 months
Capital$0~$12K$3-5M NRE
PatentsPipeline validation onlyBC-0 + BC-1 (Control Mode)BC-0 + BC-1 + BC-2 (SoC)
Combined three-phase roadmap
Phase 0 — Phone PoC
W1
USB composite + VNC
W2
OCR + patterns
W3
BT HID + AI
W4
PoC ready
Pipeline validated
SW REUSE
Phase 1 — FPGA demo
M1-2
DP RX/TX + HID
M3
OCR pipeline
M4-5
CAM + gate + E2E
M6
Demo units
Partner demos
RTL REUSE
Phase 2 — Dedicated SoC
M7-9
Arch + ASIC RTL
M10-16
Design + tape-out
M17-21
Fab + bring-up
M22-26
Production SoC
$300-500/seat
Why DisplayPort-in / HID-out

Zero-install guarantee

The host sees a display sink (DP) and a keyboard (USB HID). Both are class-compliant — every OS supports them natively with zero drivers. No software agent, no proxy, no kernel module, no IT approval. Plug in the device and the boundary exists.

Un-bypassable boundary

The device captures the screen (not intercepting software calls), so the boundary cannot be circumvented by any host software. The AI response arrives as keystrokes through a physically separate path. Design data never touches the host's network stack.
Capital deployment across all phases
ItemPhone PoCFPGA phaseSoC phase
Hardware$0 (USB cable)$7,500 (5x ZCU106)-
DP FMC / adapters-$2,500-
EDA tools$0$0 (Vivado free)$500K-1M/yr
DP PHY IP license--$300-600K
Mask & fab NRE--$1.5-2.5M
WiFi/BLE IP--$100-200K
Packaging & test--$150-300K
Certifications--$30-50K (VESA/FCC)
Engineering1 (founder, 4 wks)1 (founder, 6 mo)4-6 engineers
Total$0 + founder~$12K$3-5M
Sentridock Inc. — Phone PoC → FPGA demo → Production SoC
BC-0 / BC-1 (Control Mode) / BC-2 (SoC)