Vai al contenuto
NeoXamAgents

An AI surface you can actually secure.

Shadow AI, credential sprawl and ungoverned tool access are board-level risks. NeoXam Agents answers with one governed runtime: verified identity, per-agent roles, database-enforced tenant isolation, scoped vaults and an append-only audit log.

RBAC & tenant isolation — ShippedOIDC SSO — Beta

Identity & access

Every call authenticated, every agent role-gated

Two mandatory authorization layers stand between a user and an action: agent-level RBAC, then tool-level allow/ask/deny policies.

  • Verified JWT on every call

    Shipped

    Every API call carries a JWT verified for signature, expiry and audience — no anonymous path into the runtime, for humans or services.

  • Enterprise OIDC SSO

    Beta

    KeyCloak, Azure Entra ID and Okta-compatible OIDC with Authorization Code + PKCE lands in Beta. V0 ships passwordless magic-link sign-in with full JWT verification.

  • Per-agent RBAC

    Shipped

    Each agent declares a required role — ARO_ANALYST, DH_DEVELOPER — checked on every invocation. Access to an agent is a permission, not a default.

  • Service accounts

    Shipped

    Service-to-service calls use dedicated, rotated service accounts — products never share human credentials.

Tenant isolation

Three layers, enforced in the database

Isolation is not a middleware promise — it is row-level security on every table, derived from the verified token on every request.

01

Layer 1 — Verified tenant context

The tenant is resolved from the verified JWT on every request. No header tricks, no client-supplied tenant IDs — the token is the source of truth.

02

Layer 2 — Row-level security

PostgreSQL row-level security applies the tenant context on every table. A query without the right tenant context returns nothing — even from inside the platform.

03

Layer 3 — Scope hierarchy

Organization → workspace → agent. Workspaces are the default ownership boundary; cross-workspace access only happens through explicit organization scope.

Plus per-tenant rate limits and quotas, and per-run signed tokens for every tool call.

Secrets & vaults

No token in logs — contract-tested

Credentials authenticate tools, not prompts. They live in workspace-scoped vaults and surface nowhere else.

A vault is a logical, workspace-scoped namespace of credentials. Tokens exist only in the physical secrets store — never in descriptors, code, logs or traces. Each tool call is authenticated with a per-run signed token, so a leaked artifact never contains a long-lived credential.

The guarantee is mechanical, not procedural: telemetry passes a redaction layer with an automated contract test asserting that no prompt or completion content reaches any span, backed by sampled production audits. At GA, hardened secrets backends (HashiCorp Vault, AWS Secrets Manager) extend the same model.

  • Secrets never appear in descriptors, code, logs or traces
  • Per-run signed tokens for every tool call
  • Workspace-scoped vaults — credentials never cross tenants
  • Automated contract test: no prompt content in telemetry
  • OAuth for external tools handled via vaults (Beta)

Audit

AI your auditors can read

Auditability is the design center, not a feature flag. Every run is reconstructable, step by step, years later.

Append-only by design

audit entries are written once and never updated or deleted; the log is partitioned for regulatory retention

7-year retention design

the regulatory minimum for the vertical, configurable per tenant

Full run reconstruction

descriptor version (catalog SHA), model, ordered tool calls with inputs and outputs, tokens, cost, duration

Approvals recorded

human-in-the-loop decisions — who, when, what, why — become first-class audit entries (Beta)

CSV export

compliance roles export the trail for regulators and depositary auditors; the dedicated audit-log viewer UI ships in Beta

Bounded, curated, cancellable

Every run has hard ceilings; schema-violating output is a hard failure; agentic compute is reserved for reasoning while deterministic systems keep the books.

Containment

Bounded by design

The blast radius of any single run is declared before it starts and enforced while it runs.

  • Hard ceilings per run

    Shipped

    Max duration, max tool calls, max tokens — declared in the descriptor, enforced by the runtime. Runs are cancellable mid-flight.

  • Curated external surface

    Beta

    Third-party tools come only from a security-reviewed registry with OAuth via vaults. Arbitrary MCP endpoints are rejected.

  • Declared network egress

    Beta

    Execution environments declare their egress policy — unrestricted, host-allowlist or offline — auditable in the catalog today; runtime enforcement ships in Beta.

FAQ

Frequently asked questions

Does prompt or completion content ever appear in logs or traces?

No. Telemetry passes a redaction layer with an automated contract test guaranteeing that no prompt or completion content leaks into spans, complemented by sampled production audits. Secrets live only in the vault-backed secrets store — never in descriptors, code, logs or traces.

How is one client's data kept away from another client's agents?

Tenant isolation is enforced by construction: the tenant context is resolved from the verified token and applied as row-level security on every database table, with organization → workspace → agent scoping on top, per-workspace credential vaults, and per-tenant rate limits and quotas.

Which identity providers are supported?

Enterprise OIDC SSO — KeyCloak, Azure Entra ID and Okta-compatible providers, using Authorization Code + PKCE — ships in Beta. Today the platform uses passwordless magic-link sign-in, with full JWT verification on every API call.

How long is the audit trail retained, and can we export it?

The audit log is append-only and designed for 7-year retention, the regulatory minimum for the vertical, configurable per tenant. Compliance roles can export it as CSV. Every run is reconstructable: catalog SHA, model, ordered tool calls with inputs and outputs, tokens, cost and duration.

Can an agent call an arbitrary external API?

No. Every tool is a declared MCP server in one of three namespaces, and external tools are admitted only through a security-reviewed registry (Beta) with OAuth handled via vaults. Arbitrary endpoints are rejected, and execution environments declare their network egress policy.

General availability comes in Q3 2026. The Early Adopter Program is open now.

A limited cohort, a one-year platform trial and three workshop streams — Business ROI, Compliance, Operational fit. Bring one workflow; leave with a governed agent and the evidence to certify it.