Powerful enough for anyone. Controlled enough for the enterprise.
Imaginne was designed to be adopted by an organization — not by one user with a credit card. Identity, isolation, governance and operations are part of the product, not an add-on.
Corporate identity
Each organization signs in with its own identity: single sign-on, roles and profiles defined by the company. Nobody creates a standalone account with a credit card.
Technical details
OIDC authentication with PKCE per organization. Terminal clients use the device-code flow (RFC 8628) — no password typed outside the browser.
Governed access
What each person can use — integrations, skills, agents, models — is decided by the organization, per profile. Imaginne obeys; it doesn't improvise.
Technical details
Integration tools only load when active for the organization, the user and the surface. Sensitive capabilities are fail-closed: without explicit permission, the tool doesn't even exist for the model.
Managed credentials
API keys, database passwords and integration secrets live in a central organization vault — never in a conversation, never in a prompt.
Technical details
Secrets are organization-scoped, bound to the skills and agents that declare them, and resolved by the platform at execution time with per-step scoping. Deletion is blocked while references exist.
Delegated identity on data
When Imaginne queries your company's data, it queries as the user — with that user's permissions. Your database decides what each person sees, not the AI.
Technical details
OIDC token exchange: the query reaches the data plane with the end user's delegated identity, and the database's own access control gives the answer.
Isolated execution
All code and analysis run in an isolated, disposable execution environment — separate from your systems and from other users.
Technical details
Sandbox with kernel isolation (gVisor), read-only root filesystem, policy-restricted network egress and an ephemeral workspace per run.
Models under your control
Use the platform models or bring your own keys (BYOK). The organization defines which model each profile uses — and can switch without retraining anyone.
Technical details
BYOK is organization-scoped. Model assignment per user or profile, enforced at the gateway — the provider is abstracted away from every surface.
The questions your IT will ask
How do users authenticate?
Via OIDC with PKCE, with per-organization identity. Web and desktop authenticate through the browser; terminal clients use the device-code flow (RFC 8628). There is no Imaginne-specific password to manage.
Where do our integration credentials live?
In a central, organization-scoped vault. They are bound to the skills and agents that declare them and injected by the platform only at execution time. They never pass through the conversation and are never visible to the model beyond what the step requires.
What happens when Imaginne executes code?
Execution runs in an isolated sandbox with kernel isolation (gVisor), a read-only root filesystem and policy-restricted network egress. The workspace is ephemeral: when the run ends, the environment ends.
With which identity does Imaginne access our data?
With each user's delegated identity, via OIDC token exchange. The permissions that apply are your database's — if the user can't see a table, neither can Imaginne.
Who controls which integrations and capabilities are active?
Your organization's administrators, per profile and per surface. Behavior is fail-closed: a capability that isn't enabled simply isn't loaded.
Can we use our own model keys?
Yes. BYOK is organization-scoped, with model assignment per user or profile enforced at the gateway. You can start with the platform models and migrate later — the surfaces don't change.