Compliant AI transformation for the enterprise

AI that can prove
what it did.

Oraculum gives enterprises a control plane for AI. Every prompt, intent, file access, retrieval, model call, and action is checked before execution and recorded after completion.

Inference-level audit Permissioned ontology Open model architecture Behind the firewall

AI will become one of the greatest sources of leverage in human history. But that leverage will only reach the enterprise if organizations can trust how AI acts on sensitive knowledge. Every run permissioned. Every context decision explainable. Every action auditable. Every model interchangeable.

Before the run

Intent and access are checked first.

The compliance agent validates user identity, purpose, policy, files, subjects, tools, and actions before execution begins.

During the run

The model receives scoped context only.

Retrieval follows the permission graph, excluding blocked files, restricted subjects, and disallowed data classes.

After the run

The proof trail survives the answer.

The ledger stores tamper-evident proof while the run-detail database stores the full forensic context.

The enterprise AI control gap

AI is easy to demo.It is hard to govern.

Most enterprise AI systems can answer questions. Far fewer can prove whether the model was allowed to answer, what data it saw, which files it touched, what policy approved the run, and how the final response was produced. That is the blocker for regulated enterprises.

No audit at the level that matters +

Most systems log the final answer. Compliance teams need the full chain: prompt, inferred intent, selected files, retrieved context, policy decision, model response, and resulting action.

HIPAA requires 6-year retention with unique user identification for every data access event. SOX mandates 7-year audit work paper retention. EU AI Act Article 12 requires high-risk AI systems to maintain operational logs for at least 6 months. Most AI systems log session-level events — not the operation-level detail these frameworks demand. Oraculum captures the full chain: prompt → inferred intent → file selection → context retrieval → policy decision → model response → final action, each with cryptographic timestamps and user attribution.

Permissions break when data becomes context +

Enterprise permissions live across SharePoint, Drive, file systems, data warehouses, CRMs, tickets, wikis, and code repositories. AI systems often flatten those controls into unmanaged text chunks.

The EchoLeak vulnerability demonstrated against Microsoft 365 Copilot in late 2025 showed how a crafted email could manipulate a RAG pipeline to retrieve and exfiltrate data the attacker had no access rights to. OWASP LLM08:2025 formally categorizes vector and embedding weaknesses, including multi-tenant retrieval failures where a marketing query for "revenue trends" retrieves the finance team's confidential forecasting embeddings because they are semantically proximate in a shared vector space. 72% of enterprise RAG implementations fail in the first year, with Forrester attributing 67% of failures to data governance issues, not retrieval algorithms.

Model stacks keep changing +

Enterprises need to use OpenAI, Anthropic, Google, Bedrock, Azure, private models, and specialist partner tools without rebuilding governance every time.

MCP (Model Context Protocol) was introduced by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, now co-governed by Anthropic, Block, and OpenAI. By March 2026: 10,000+ active public MCP servers and 97 million monthly SDK downloads. The AI Gateway pattern routes requests across providers (OpenAI, Anthropic, Google, Bedrock, Azure, on-premises models) with unified credential management, rate limiting, policy enforcement, and audit logging. Oraculum implements this pattern with governance built into the routing layer.
The Oraculum layer

One control layer for compliant AI execution.

Oraculum sits between enterprise systems and AI models. It understands who the user is, what they are asking for, which files and subjects are involved, what policy allows, and which model or tool should handle the work.

Before the run proceeds, Oraculum validates access and intent. During the run, it limits retrieval to approved context. After the run, it stores a complete audit record.

01
User submits prompt via any AI interface
02
Compliance agent reviews intent, access, policy
03
Validation token issued, scoped to run
04
Retrieval limited to approved context
05
Audit record stored to hash-chain ledger
Core capabilities

Three promises to the enterprise.

01

Fully Auditable AI +

Every AI run becomes evidence. Oraculum records the exact prompt, inferred intent, selected sources, retrieved context, compliance decision, validation token, model response, and final action.

  • Prompt and intent logging
  • Signed compliance validation
  • Hash-chain run ledger
  • Full run-detail database
  • Source and context trace
  • Human approval and override history
Each audit record is structured as a hash-chain: hash(record_n) = SHA-256(content_n + hash(record_{n-1})). If any historical record is modified, its hash changes, breaking the chain for every subsequent record — tampering is mathematically detectable, not just policy-prohibited. Merkle tree aggregation groups records into leaves, enabling efficient verification of any subset without replaying the full log. External anchoring publishes the root hash to a timestamping authority for independent verification. This architecture satisfies MiFID II, SEC Rule 17a-4, and EU AI Act Article 12 tamper-evident audit requirements.
02

Permissioned Knowledge Ontology +

The model only sees what policy allows. Oraculum maps enterprise knowledge into a live ontology of files, folders, subjects, users, groups, data classes, owners, lineage, and retrieval permissions.

  • File-level permissions
  • Folder-level inheritance
  • Subject-level restrictions
  • Semantic policy controls
  • Data classification
  • Retrieval depth controls
  • Compliance-colored knowledge graph
Unlike vector search that flattens permission models at ingest time, Oraculum maintains an explicit ontological graph: document → owner → access policy → classification tier → retrieval rule. Each node carries its own ACL inherited from the source system (SharePoint, Google Drive, Confluence, Salesforce). At retrieval time, the ontology enforces permission checks per chunk — not per query. Data classification tags (public, internal, confidential, restricted) travel with every piece of retrieved context, preventing the silent cross-class mixing that OWASP LLM08:2025 identifies as a systemic RAG vulnerability.
03

Open, Future-Proof Architecture +

Use any model. Keep one control layer. Oraculum is model-neutral. It can route work to frontier models, private models, cloud model catalogs, coding agents, and partner-built AI workflows.

  • OpenAI, Anthropic, Google, Bedrock, Azure
  • MCP-compatible architecture
  • Partner agent integration
  • Model routing by cost, latency, quality
  • No lock-in to one AI vendor
  • Governance travels with the buyer
The AI Gateway layer handles request routing by cost, latency, and capability tier. Credential management is per-vendor with automatic rotation. Policy enforcement blocks data-classified prompts from leaving the network perimeter when required. Unified audit logging captures every model interaction regardless of provider. Swapping a downstream model requires zero application changes. This architecture supports frontier models (GPT-4o, Claude, Gemini), private fine-tuned models, cloud model catalogs (Bedrock, Azure AI), coding agents (Claude Code, Copilot), and partner-built vertical AI workflows through MCP.
How Oraculum governs an AI run

From user prompt to audited execution.

Step 01

Map the enterprise +

Connect to enterprise sources and build an ontology of files, folders, systems, users, groups, subjects, data classes, and permissions.

Oraculum connects via native APIs, MCP servers, event streams, and file system watchers. It indexes structure and metadata — not content. Data stays in source systems. The ontology maps files, folders, users, groups, roles, data classes, ownership chains, and permission inheritance trees. Initial mapping typically covers SharePoint, Google Drive, local file systems, CRM, ERP, data warehouses, wikis, ticketing systems, email, and code repositories.
Step 02

Understand the request +

When a user submits a prompt, the user-facing AI proposes what it needs to do: which files, tools, actions, and systems may be required.

Intent classification uses a dedicated analysis pass — separate from the execution model — to determine what the user is actually asking for. This includes: which enterprise systems are implicated, what data classes may be involved, what actions are being requested (read, write, summarize, generate, execute), and what the downstream effect could be. The classification feeds directly into the compliance review.
Step 03

Validate with compliance +

A separate compliance agent reviews the exact prompt, inferred intent, user access, file ontology, subject policy, and requested actions.

The compliance agent is architecturally isolated from the execution path. It receives the classified intent, the user's identity and role, the relevant file ontology nodes, applicable subject policies, and the requested actions. It evaluates each element against the current policy version and produces a structured decision: approve, deny, or escalate to human review. The decision includes a complete reasoning chain for auditability.
Step 04

Issue a validation token +

If the run is allowed, Oraculum issues a signed validation token scoped to that user, prompt, policy version, tools, resources, and time window.

Validation tokens are cryptographically signed, scoped, and time-bounded. Each token encodes: the approving policy version, the user identity, the specific prompt hash, the approved file set, the approved action types, the model routing decision, and an expiration window. Tokens cannot be reused across prompts, users, or time windows. The signing key is managed separately from the production system.
Step 05

Retrieve only approved context +

Oraculum retrieves context at the allowed level: metadata, summary, chunk, document, SQL result, or live system query.

Retrieval operates at six distinct levels depending on the context type and policy: metadata-only (file name, owner, date), summary (AI-generated document summary), chunk (standard text segment), full document, structured query (SQL against source systems), or live system query (real-time API call to source). The retrieval level is determined per-source by the policy engine, not by the user or the execution model.
Step 06

Record the full run +

The run is written to an audit trail. The hash-chain ledger stores the proof trail. The run-detail database stores the full forensic record.

Two parallel records are created. The hash-chain ledger stores the cryptographic proof trail — each record's hash incorporates the previous record's hash, making the chain tamper-evident. The run-detail database stores the complete forensic record including full prompt text, all retrieved context, the complete model response, and the compliance reasoning. Both records are immutable and retained according to the applicable regulatory schedule.
Architecture

Enterprise systems in. Governed AI out.

Oraculum does not replace enterprise systems. It sits above them as a permissioned context and execution layer. Data stays in the systems of record. Oraculum indexes structure, policy, identity, lineage, and retrieval rules so AI can use the right context safely.

Enterprise Systems
SharePointDocument libraries, team sites, and permission groups synced via Microsoft Graph API Google DriveFile hierarchy, sharing permissions, and organizational units via Drive API File SystemsLocal and network file systems indexed via file watchers with ACL inheritance CRMCustomer records, opportunity data, and role-based field visibility from Salesforce, HubSpot, or Dynamics ERPFinancial records, journal entries, and control evidence from SAP, Oracle, or Workday Data WarehousesStructured analytics data with column-level security from Snowflake, BigQuery, or Redshift WikisKnowledge base articles and page-level permissions from Confluence, Notion, or internal wikis TicketsIssue tracking with project-level access from Jira, ServiceNow, or Zendesk EmailMessage metadata and attachment indexing with mailbox-level permissions Code ReposRepository access, branch permissions, and file-level CODEOWNERS from GitHub or GitLab
↓ Connectors · APIs · MCP · Event Streams ↓
Oraculum Control Layer
Context CompilerAssembles governed context packages from multiple sources with classification tags and permission metadata File OntologySemantic graph of files, folders, subjects, owners, and relationships across all connected systems Permission GraphUnified permission model mapping users → roles → groups → resources across all source systems Compliance AgentIsolated AI agent that reviews intent, access, and policy before any execution proceeds Policy EngineDeclarative rule engine for retrieval scope, blocked subjects, data class boundaries, and escalation triggers Retrieval RouterRoutes context requests to the appropriate retrieval level: metadata, summary, chunk, document, SQL, or live query Audit LedgerAppend-only hash-chain log providing tamper-evident proof of every compliance decision and AI action Run-Detail StoreFull forensic database storing complete prompts, context, responses, and compliance reasoning chains Model GatewayAI provider router handling credential management, rate limiting, policy enforcement, and unified logging
↓ Governed Context API · Retrieval · Live Query · Citation ↓
AI Execution
OpenAIGPT-4o, GPT-4.5, and o-series reasoning models via API with usage tracking and cost allocation AnthropicClaude Opus, Sonnet, and Haiku models with extended context and tool use capabilities GoogleGemini models via Vertex AI with enterprise data residency controls AWS BedrockMulti-model catalog with VPC-private endpoints and AWS IAM integration AzureAzure OpenAI Service with regional deployment and Azure AD authentication Private LLMsSelf-hosted fine-tuned models running on-premises or in private cloud with full data sovereignty Coding AgentsClaude Code, GitHub Copilot, and Cursor with pre-execution validation and secrets scanning Partner AgentsThird-party vertical AI tools integrated via MCP with governed data access Workflow AutomationsMulti-step AI workflows with human-in-the-loop gates and action-level audit trails
Compliance control center

Audit every prompt, intent, retrieval, and model action.

The Oraculum compliance control center gives teams a live view of how AI is being used across the enterprise. Inspect the run ledger, retrieve full run details, review denied requests, trace context exposure, and prove how policy was enforced.

Run Ledger +

A signed hash-chain record of prompts, proposed runs, compliance reviews, validation tokens, retrievals, model calls, and completed actions.

The ledger implements append-only storage with cryptographic sealing at configurable intervals (every 1,000 events or every 60 seconds). A sidecar audit service runs isolated from production systems with separate key management, so production system compromise does not enable log falsification. Each entry captures: timestamp, user identity, prompt hash, inferred intent classification, policy version applied, compliance decision (approve/deny/escalate), validation token ID, retrieved sources with classification tags, model provider and model version, response hash, and resulting action type.

Run Detail Store +

A separate database containing the full prompt, inferred intent, selected files, retrieved context, model response, compliance rationale, and final outcome.

While the ledger stores the cryptographic proof trail, the detail store contains the full forensic record: complete prompt text, inferred intent with confidence score, every file considered and why each was included or excluded, the full retrieved context with source attribution, the complete model response, the compliance agent's reasoning chain, any human approval or override events, and the final outcome with effect classification. Retention policies are configurable per regulation: 7 years for SOX-material records, 6 years for HIPAA, 6 months minimum for EU AI Act.

Policy Console +

Admins can define retrieval rules, blocked subjects, restricted subjects, allowed purposes, data classes, and semantic compliance guidelines.

The console provides a declarative policy language for compliance administrators. Rules can target: retrieval scope (which files, folders, or subjects a role can access), blocked subjects (topics that must never enter a model context), purpose restrictions (limiting AI use to approved business purposes), data class boundaries (preventing confidential data from being sent to external models), semantic compliance guidelines (custom rules like "never generate content that could be interpreted as financial advice"), and escalation triggers (conditions that require human approval before execution).

Ontology Viewer +

Compliance-restricted nodes appear directly in the knowledge graph, making policy visible at the file and subject level.

The viewer renders the enterprise knowledge graph with compliance coloring: green nodes are fully accessible, amber nodes require elevated permissions, red nodes are blocked by policy. Administrators can inspect any node to see its access policy chain, data classification, owner, last-modified timestamp, and retrieval history. The graph supports drill-down from folder level to individual document level, showing which AI runs have accessed each node and under what policy authorization.
Future-proof AI infrastructure

Models will change. Your governance should not.

The enterprise AI stack is still moving. New frontier models, private models, coding agents, and vertical AI products will continue to emerge. Oraculum gives companies a stable control layer underneath that change.

With Oraculum, enterprises can adopt new AI partners without rebuilding identity, permissions, retrieval, compliance, and audit from scratch.

For AI partners

Oraculum provides a governed path into regulated enterprise environments.

For enterprise buyers

Oraculum keeps leverage: models and applications can be swapped, but the control layer remains owned by the enterprise.

Where Oraculum starts

Workflows where proprietary knowledge meets high-friction work.

AI Coding Harnesses +

Validate developer intent, repository access, file permissions, shell commands, secrets boundaries, and deployment actions before coding agents execute.

GitGuardian's 2026 report found 28.6 million secrets exposed in public GitHub commits in 2025 — a 34% year-over-year increase. AI-service secrets grew 81% year-over-year. Commits co-authored by AI coding agents leaked secrets at roughly double the baseline rate. 68% of organizations lack visibility into which AI coding tools developers use. Oraculum validates developer identity, repository scope, file-level permissions, shell command allowlists, secrets boundaries, and deployment targets before any coding agent executes. Every code generation, file modification, and deployment action is recorded with full provenance.

Regulated Document Workflows +

Draft, review, and answer from sensitive documents while preserving privilege, source lineage, data classifications, and audit trails.

Attorney-client privilege attaches to the communication, not the document format. AI-drafted privileged documents require controls ensuring the draft never traverses non-privileged infrastructure — the AI system must be isolated from general enterprise search indexing. FedRAMP requires continuous monitoring of any AI system processing controlled unclassified information. Oraculum maintains privilege boundaries, tracks source lineage per paragraph, enforces data classification at the retrieval level, and generates audit trails that satisfy SOX, HIPAA, GDPR Article 30, and EU AI Act Article 12 simultaneously.

Finance and Audit +

Use AI across close, reconciliation, variance analysis, and control evidence without turning structured ERP data into unmanaged embeddings.

SOX Section 404 requires management and external auditors to assess internal controls over financial reporting. AI tools influencing journal entries, reconciliations, or revenue forecasting must be scoped into ITGC and application control testing. Oraculum provides documented model inputs and outputs, change management trails, and human review gates. GRC teams using Oraculum can deploy continuous control monitoring for evidence collection, sample testing, and journal entry analytics — targeting 20-30% reduction in manual testing hours after two cycles.

Customer and Claims Operations +

Resolve customer issues and claims across systems while respecting PII, jurisdiction, escalation policy, and role-level access.

CCPA (amended by CPRA) grants consumers rights over automated decision-making technology. California Privacy Protection Agency regulations require risk assessments, cybersecurity audits, and ADMT disclosure. GDPR Article 22 requires human review availability for any automated decision with legal or significant effect. In insurance, NAIC Model Laws plus state Department of Insurance rules create overlapping obligations. Oraculum enforces role-based access — licensed adjusters see claim financials, frontline agents see case status only, supervisors see escalation queues — with every access decision audited.

Enterprise Knowledge Search +

Search thousands of files and systems through a permissioned ontology rather than a blind vector index.

Pure vector search fails in enterprises for three structural reasons. First, source system ACLs (SharePoint, Confluence, Salesforce) do not travel with chunks — the EchoLeak vulnerability exploited this exact gap. Second, semantic boundary violation means a marketing query retrieves finance team embeddings because they are proximate in vector space. Third, vector similarity cannot model organizational hierarchies, classification levels, or document lineage. Oraculum's ontology maintains explicit relationships that persist through retrieval, with permission enforcement at query time.
Beyond RAG

RAG retrieves chunks. Oraculum governs context.

Vector search is useful, but it is not a governance architecture. Enterprises need to preserve identity, permission, ownership, lineage, freshness, subject policy, and auditability.

The RAG-everything reflex

  • Chunks lose ownership, sensitivity, and lineage When a 50-page contract is split into 500-word chunks, the chunk containing salary data loses its "HR-Confidential" classification and becomes searchable by any role.
  • Permission models are flattened at ingest time A SharePoint document restricted to the Legal team becomes a chunk in a shared vector index — the original ACL is not queryable at retrieval time.
  • Structured records get distorted into prose An ERP journal entry with 12 structured fields becomes a prose paragraph, losing the field-level validation and cross-reference integrity that auditors require.
  • Stale embeddings drift from systems of record When a policy document is updated in SharePoint, the vector index still serves the old embedding until a full re-index — with no staleness indicator to the model or user.
  • Cross-source reasoning silently mixes data classes A query that pulls from both HIPAA-covered patient records and public HR policy creates a response that crosses classification boundaries with no audit trail of the mixing.

The Oraculum approach

  • A semantic graph over systems — not a copy of them The ontology indexes structure, ownership, and relationships — not content. Source data stays in place. Oraculum knows what exists, who owns it, and what policy governs access.
  • Live query for sensitive structured data Instead of embedding ERP data, Oraculum executes a governed SQL query at retrieval time, returning fresh results with field-level access controls intact.
  • Scoped retrieval where text genuinely belongs Unstructured documents are retrieved as text chunks only when the content type and classification permit embedding. Structured data is never embedded — it is queried live.
  • Embeddings only where governance permits The policy engine determines which documents can be embedded (e.g., public knowledge base articles) vs. which must be retrieved via live query or metadata-only.
  • Every answer carries source, permission, and policy Each piece of retrieved context includes: source system, document ID, owner, classification tier, retrieval level, policy version that authorized access, and timestamp.
Why now

AI adoption is moving faster than AI governance.

Enterprises are deploying more models, more agents, and more AI workflows. At the same time, regulators, customers, boards, and internal risk teams are asking harder questions about data access, explainability, and accountability.

AI represents a once-in-a-generation increase in human leverage. It can compress product cycles, lower the cost of services, accelerate operations, and expand the frontier of scientific discovery. The missing layer is not another model. It is the control plane that lets enterprises use many models safely.

Request access

Bring us the workflow you want AI to handle safely.

We are working with regulated enterprises and AI partners that need auditable, permissioned, model-neutral AI execution. Tell us which systems, workflows, and compliance requirements matter most. We will come prepared.

Enterprise & partners
team@oraculum.tech
Press & analyst
press@oraculum.tech