AI on governed data. That's the whole idea.
An MCP server exposes the live schema to AI clients, business rules are authored by prompt and test-gated before they run, and every agent inherits the same enforcement as a human user.
- ·An AI agent gets a session the same way a person does, and everything it reads or writes goes through the same tenant scoping, permissions, and audit.
- ·Business rules are described in plain language, generated as C#, compiled in a sandbox, and blocked from publishing until their tests pass.
- ·When a rule fails in production the failing data becomes a permanent regression test, and rules can be regenerated when a better model ships.
Most enterprise AI is a chatbot pointed at data nobody governed.
The failed-pilot statistics all trace back to the same decision: AI was added on top, not built on a foundation. The model could read too much, prove too little, and integrate with nothing. Security teams were right to object.
The fix isn't a smarter model. It's a data layer where access control, tenancy, and audit are enforced below the AI, so the model's mistakes can't become breaches.
The mechanisms, not the adjectives.
Agents inherit enforcement
AI agents authenticate and get sessions like any user. Every read and write they make goes through the same data path: tenant scoping from the foreign-key walk, permission keys, column security, injection scrubbing, audit. There is no separate, weaker AI door.
The CISO objection to AI over corporate data has a structural answer, not a policy answer.
A purpose-built MCP server
The platform ships a Model Context Protocol server exposing the live database: schema introspection, search, foreign-key graphs, and governed write tools for platform artifacts. MCP moved to the Linux Foundation in December 2025 with AWS, Google, Microsoft, and OpenAI behind it.
AI assistants read the actual data model instead of guessing at it, over the industry standard rather than a proprietary bridge.
Rules authored by prompt, gated by tests
A business analyst describes a validation rule in plain language. The platform generates the C# implementation, grounded in the schema, compiles it, and runs it in a hard sandbox: no database access, no file or network access, allow-listed namespaces, per-rule time budgets. Publishing is blocked while any saved test fails, and rule changes go through a draft, approval, and publish lifecycle with a full audit trail.
Business rules change in production without a release cycle, and without giving up ownership, approval, or test coverage.
Self-healing with regression capture
When a published rule fails at runtime, the failure is captured and deduplicated. The studio proposes a fix, the failing payload becomes a permanent regression test, and the corrected rule re-publishes only when tests pass.
Every failure makes the system permanently harder to break. The same problem doesn't ship twice.
Regenerate on model upgrade
The prompt is the durable source of intent; the generated code is a readable, editable artifact. When a better model ships, rules can be regenerated from their prompts, re-tested, and re-launched. Extending this beyond validation to data enrichment and event handling is on the roadmap.
Most tools treat generated code as a one-time artifact that decays. Here customizations get better as models do.
From plain language to a running production rule.
- 1
An analyst writes: invoices over $50,000 for new vendors need a second approval reference.
- 2
The platform generates the C# validator, grounded in your actual invoice schema, and compiles it in the sandbox.
- 3
Generated tests run, including edge cases. Publishing stays blocked until they pass.
- 4
An approver reviews and publishes. The rule now runs live in every editor and as a commit gate on save.
- 5
Months later it fails on a data shape nobody predicted. The failure is captured, a fix is proposed, and the failing payload becomes a regression test before the rule goes live again.
The AI angle.
This page is the AI angle. The distinction worth keeping: most vendors point AI at the end user as a chat window. Forge points it at the builder and the operator, on top of a security engine that makes the AI's output safe to run. That order of operations is why it works.
Keep going.
Security & multi-tenancy
Tenant isolation derived from foreign keys and enforced in one data path. No filter to forget.
Go deeper →Integration & automation
Background automation that obeys the same tenant boundaries as interactive users.
Go deeper →Developer experience
One command scaffolds a secure full-stack app. AI assistants learn the conventions from day one.
Go deeper →See it on your schema, not ours.
A fixed-price assessment gets this running over your actual data.