AI Governance
When an engineer uses AI to write code at a bank, an energy company, or a defense contractor, three questions matter to the organisation: which model touched that code, what did it have access to, and who authorised it.
Neural Inverse Enterprise answers all three.
Model Access Control
The org admin decides which models are available to which teams. Developers work within that policy. They cannot route around it - enforcement runs server-side, not in the IDE client.
Configure the policy once in the Console. It propagates to every connected IDE within 30 seconds.
Enforced mode - developers can only use models the org has approved. Personal API keys are blocked at the policy layer. A developer who tries to use an unapproved model sees a policy error, not a broken tool.
BYOLLM mode - developers configure their own credentials. The org can still restrict which providers are allowed and which models within those providers are accessible.
Mixed - some tiers org-managed, others developer-configured. Useful when the organisation handles credentials for premium models but allows developers to bring their own keys for experimentation.
Per-Project and Per-Developer Controls
The IAM policy engine scopes controls at four levels: org, project, subproject, and individual developer. A policy set at a lower level overrides the one above it.
This means:
A standard developer on most projects can use the full model lineup. A developer on a payments module can have Power Mode terminal access blocked entirely. A senior engineer on that same module can have it re-enabled. A compliance officer can have read-only access to checks data and no AI development features at all.
None of this requires separate accounts or separate IDEs. It is policy, applied at connection time, enforced at every request.
Agent Execution Controls
Autonomous agents - Power Mode, Workflow Agents - operate inside the same governance framework. The org sets limits that apply to every agent session regardless of what the developer configures:
- Maximum iterations per session - prevents runaway loops in production-adjacent workflows
- Maximum concurrent sub-agents - controls compute and review overhead
- Auto-approve policy per tool type - the org can require human approval before any terminal command executes, or allow auto-approve for file edits but not for git operations
- Lock developer settings - prevents developers from loosening the controls the org set
These settings are in the Console under Manage > Agents. They apply immediately to all active sessions.
Audit of Every AI Action
Every model request, every agent tool call, every approval and denial is written to the audit trail. The record includes which model was used, what policy was active at the time, whether the Enclave flagged anything in the context, and who approved the action if approval was required.
The audit trail is immutable and exportable as a structured evidence bundle. A compliance officer can hand it to a regulator and verify its integrity with a hash check.
Developer Request Workflow
When a developer needs access to a capability that policy does not currently allow - a new model, a tool permission, an exception for a specific project - they submit a request from inside the IDE. The request appears in the Console with full context. The admin approves or denies with a note. The decision is logged.
This converts the common situation - a developer working around policy because the approval path does not exist - into a governed, auditable process. The organisation can say yes to AI tools because it now has a way to say yes safely.
Available in Enterprise
AI Governance is a Neural Inverse Enterprise feature, available on platform.neuralinverse.com and in on-premises deployments.