Platform Architecture
One platform. Both directions. Many enforcement points.
Inbound
hostile content stopped before it becomes AI context
Shared Core
one policy decision point · one evidence chain
Outbound
secrets and PII stopped before they leave
URL & Context Trust Gate
Phishing, hidden promptware, and hostile web content evaluated — and detonated in an isolated sandbox when needed — before a human, browser, endpoint, app, or AI agent ingests it.
Policy Engine + Evidence Store
Detection — prompt injection, 21 redaction classes, dangerous output, toxicity — feeds one OPA-backed engine that decides allow, warn, redact, block, or isolate. Every decision is persisted as tenant-scoped evidence bound to the control that produced it.
Redaction & Response Enforcement
Secrets and PII redacted before they leave. Dangerous output detected on the way out — an AI response carrying a shell command, a script injection, or a browser-data-exfil pattern (OWASP LLM02) — and responses policy-routed to approved providers.
Enforcement points — every surface calls the same decision point and writes to the same evidence chain
Endpoint Agent
Windows · macOS · Linux — with policy-gated patch remediation
Browser · VS Code · Office
Extensions gating context and redacting at the prompt surface
RASP + SDKs
In-app enforcement across 9 languages
SIEM Forwarders
Splunk, Sentinel, QRadar, Elastic, Google SecOps, syslog/CEF — 6 connectors
ROS 2 Robotics Agent
Actuator policy validated on physical hardware
Nothing drawn here is roadmap. The one kernel-level roadmap item — the unsigned Windows minifilter driver — lives on the status register until it ships.
Nine Runtime Capabilities.
One Integrated Control Loop.
Each capability can support a focused pilot, but the real value is the loop: gate in, detect, enforce policy, redact out, record evidence — one decision point behind every surface, inbound and outbound.
Maturity chips come straight from the capability-status register; a card spanning production and pilot capability wears the lower tier.
URL & Context Trust Gate
A pre-ingestion control point that evaluates URLs and external content before a human, browser, endpoint agent, RASP-instrumented app, or AI agent fetches them. Existing URL filters answer 'is this site malicious for a human?'; CyberArmor.AI also answers 'is this content safe for an AI agent to ingest?' A 15-minute local PoC is available.
Key Capabilities
- Canonicalisation, querystring redaction, and homoglyph / punycode checks before any network call
- SSRF-guarded safe crawl plus optional Playwright detonation to surface CSS-hidden, off-screen, and Unicode-tag-encoded promptware
- Detection-service fan-out for phishing, hidden prompt injection, promptware, data-exfil, and IOC scoring with optional Safe Browsing v4, Microsoft SmartScreen, and VirusTotal reputation feeds
- Policy decisions across allow, warn, redact, sandbox, block, and isolate — with evidence written to audit
AI Asset Discovery & Inventory
You cannot control what you cannot see. CyberArmor.AI uses endpoint, browser, API, and integration signals to surface AI tools, model calls, provider connections, and agent activity.
Key Capabilities
- Discovery signals for shadow AI tools and unauthorized model connections
- Tenant-scoped inventory views for AI systems, APIs, agents, and workloads
- AI Bill of Materials (A-BOM) across endpoints, repositories, and cloud, with OSV-backed CVE matching enriched by CISA KEV and FIRST EPSS exploit-prediction scoring
- Monitoring for new AI activity, software drift, and newly exploitable components across endpoints, repositories, and cloud sources
Policy Enforcement Engine
CyberArmor.AI translates governance requirements into executable policy decisions tied to tenant, actor, workload, model, provider, data, and risk context.
Key Capabilities
- Tenant-scoped policy rules for AI access, routing, redaction, blocking, and monitoring
- Context-sensitive evaluation based on risk posture, data sensitivity, provider, and actor context
- OPA-backed evaluation with a Python fallback path
- Artifact references and policy outcomes preserved in evidence records
Runtime Protection
Runtime protection means acting when AI activity happens, not simply reviewing logs later. CyberArmor.AI connects detection and policy to enforcement outcomes in both directions — prompts and context on the way in, responses on the way out.
Key Capabilities
- Inspection of AI API calls, model queries, prompt fields, SDK requests, and agent actions
- Prompt injection detection, credential leak detection, and sensitive-data inspection
- Dangerous-output detection on the way out: AI responses carrying shell commands, script injections, or browser-data-exfiltration patterns are caught before they reach downstream systems (OWASP LLM02)
- Adaptive enforcement: monitor, warn, block, redact, route, limit, or redirect
- Protection patterns for AI chatbots, LLM-powered applications, developer workflows, and autonomous workflows
Identity-Aware Trust Controls
In AI environments, identity is not just about users. CyberArmor.AI models humans, services, workloads, and AI agents so security teams can reason about who or what acted.
Key Capabilities
- Enterprise single sign-on (OIDC) with just-in-time provisioning and multi-factor authentication (TOTP + backup codes), plus directory identity enrichment from Microsoft Entra ID, Okta, Ping Identity, and AWS IAM Identity Center
- Every audit event, action-graph node, telemetry record, and incident resolved to a real named user, department, and directory group
- Agent registration, tenant scoping, owner metadata, allowed and denied tools, delegation chains, and revocation paths
- Cross-domain trust decisions spanning human, service, workload, and AI actor types
Evidence & Decision Traceability
CyberArmor.AI preserves evidence attached to controls: actor, request, provider, data classification, policy decision, response action, and downstream trace context.
Key Capabilities
- Decision-level telemetry for AI actions, model calls, and agent behavior
- Audit-chain modeling with trace IDs, span IDs, chain hashes, signatures, and previous-event references
- Tenant-scoped, PostgreSQL-persisted evidence and assessment storage — evidence bound to the control decision that produced it
- Evidence export patterns for SOC, audit, legal, compliance, and executive review
Detection, Enforcement & Response
CyberArmor.AI closes the loop from detection to policy to enforcement to response. When a threat or policy violation is identified, the platform records context and can trigger approved actions.
Key Capabilities
- Response actions for AI-specific threat scenarios, including block, notify, ticket, webhook, and containment patterns
- Real per-connector SIEM forwarding to Splunk, Microsoft Sentinel, IBM QRadar, Elastic, Google SecOps, and syslog/CEF
- Structured alert context: policy violated, actor identity, action taken, evidence ID
- Containment capabilities: redaction-mode response, agent suspension, scope reduction, access revocation, and routing changes
Endpoint Protection & Patch Remediation
The same endpoint agent that carries AI governance to the device protects the device itself. Beyond monitoring AI activity, it delivers real-time malware detection and automated, policy-gated software patching across Windows, macOS, and Linux.
Key Capabilities
- Cross-platform patch remediation through native package managers (winget, Homebrew, apt, yum/dnf), gated by maintenance windows, approval workflows, and per-application auto-approve
- Signature and hash-reputation malware detection with a control-plane-synced intelligence feed and optional YARA rules
- Software-update inventory: every endpoint reports what is outdated and exploitable, prioritized by CVE, CISA KEV, and EPSS
- Every privileged action runs through a single audited broker, producing tamper-evident, decision-level evidence
Compliance & Attestation
Controls and evidence map to the regulatory language your auditors and boards already use. CyberArmor maps enforceable controls to established frameworks and preserves the assessment evidence tenant-scoped and persisted — purpose-built for regulated industries including financial services.
Key Capabilities
- 17 framework policy packs, including ISO/IEC 42001 (AI management systems), SEC Cyber, FINRA Cyber, NYDFS 500, SOC 2, ISO 27001, PCI DSS, NIST CSF, NIST 800-53, NIST AI RMF, CMMC L3, GDPR, and CCPA
- Enforceable control templates mapped to runtime policy — compliance requirements that become executable decisions, not documents
- Per-request evidence submission and retrieval, plus persisted assessment reports scored per framework
- Attestation-ready exports for auditors, regulators, and executive review
From Prompt to Actuator.
Most AI-security products stop at the gateway. CyberArmor's policy decisions are enforced at the prompt surface, on the endpoint, into the SIEM, and — a place enforcement almost never reaches — on the robot itself.
The prompt
Browser, VS Code, and Office extensions gate context and redact at the point of use — before a paste, a fetch, or a send.
The endpoint
One agent on Windows, macOS, and Linux: AI governance, malware detection, and policy-gated patch remediation through an audited broker.
The SIEM
Structured verdicts — policy violated, actor identity, action taken, evidence ID — forwarded to six connectors your SOC already watches.
The actuator
The ROS 2 agent enforces velocity policy on the wire: a 9.0 m/s command against a 2.0 m/s limit reached the motor driver at 2.0 m/s.
A Poisoned Checkpoint Lands on One Laptop.
The diagram above says one policy plane. This is what that means when a single artifact hits a single developer's machine: inspected without being run, described precisely enough to act on, evaluated against the same policy service that governs every other surface, and recorded once.
The write is seen. The file is read, not run.
A checkpoint lands in a developer's Downloads folder. The endpoint file monitor sees the write and hands the artifact to the model scanner, which disassembles the pickle opcode stream statically — including torch ZIP checkpoint members stored deflated, which a byte-signature scan cannot see at all. The artifact is never unpickled, loaded, or executed. A file that trips the detector is reported, never run.
Static disassembly of the opcode stream — no pickle.loads, no import, no execution
A severity-rated finding, not a log line.
The finding carries the rule that matched, the module and callable it found, and why that matters — rated critical because the callable runs a shell command the moment the model is loaded. Detection is keyed on how dangerous callables actually serialise: the pickler records posix.system, not os.system, so posix.system is what the scanner looks for. The pickle memo is emulated, so a module reference the pickler rebuilt across several opcodes still resolves to the same pair.
model.pickle.posix.system · critical · “executes a shell command on load”
Evaluated on the policy service every surface shares.
The finding becomes an event, evaluated against that tenant's policy on the same OPA-backed policy service that governs the browser extension, the AI proxy, the VS Code extension, the RASP-instrumented application, and the ROS 2 robotics agent. A rule written once applies wherever it is relevant: the laptop is governed by the same decision point as the proxy, and the outcome recorded is detection, event, policy decision, evidence.
One decision point — the same one drawn at the centre of the architecture diagram
One queryable record at audit time.
The decision is written to the hash-chained, signature-bound audit log with trace IDs, span IDs, and a previous-event reference, tenant-scoped and bound to the control that produced it. What was found, what policy said, and what happened is one record you can query — rather than three consoles to reconcile when an auditor asks.
Chain hash · signature · previous-event reference · trace and span IDs
Scope of this chain. For a model artifact the chain is detection, event, policy evaluation, and evidence — the checkpoint is reported, evaluated, and recorded. Verified coverage today is raw pickle streams and torch ZIP checkpoint members, plus a deliberately narrow Lambda and marshalled-bytecode check for Keras; the status register lists what each scanner reads and what it does not. The policy engine and evidence chain these steps call are production-deployed and shared with every other surface, while the endpoint inspection and detection that feed them are pilot-ready — so the chain is shown at the lower of the two tiers throughout.
Built to Work With Your Existing Stack.
CyberArmor.AI extends your security investment — integrating with the identity, cloud, and security platforms your team already relies on.