SAML single sign-on and one source of tenant and user identity. Every call carries the assertion and is validated before any work runs. Guardrails check every model call, and every call, token and error lands in one log pipeline, per tenant and per user.
No lock-in to any one provider: switch or mix them without changing an agent. A single LLM gateway enforces guardrails, rate limits and provider fallback, with central logging and cost visibility. No other service holds provider credentials.
The orchestrator and agents speak A2A. Each specialist advertises an agent card, so a new Python agent joins without touching the orchestrator. Tools sit behind MCP, execution-only, with role-based access and masked data.
Every configuration change is proposed by a maker and approved by a different checker before it takes effect. Each step is recorded in an audit trail of who changed what, when, and who approved it.
The browser authenticates at the identity provider over SAML 2.0 and receives a single sign-on session.
Each downstream call carries the SAML assertion: A2A to agents, MCP to tools, and LLM calls to the gateway.
The receiving service checks the assertion with the identity provider first. No assertion, no execution.
Read more: NIST SP 800-207, Zero Trust Architecture ↗ · SAML 2.0 technical overview (OASIS) ↗
Security headers on every response, rate limiting, input validation, a request-size guard, and an encrypted payload channel for each session. Errors never leak internals. An automated OWASP smoke test suite checks these protections. About the OWASP Top 10 ↗
Guardrails check the user's question before a model sees it, and the answer before the user sees it. Model calls are rate limited per user, with limits on tokens and size. Every tool runs its own checks, and access follows the user's role. About the OWASP Top 10 for LLM applications ↗
One database for tenant data and, with pgvector, for vector search. This is all you need to run the platform.
Session data, when you want sessions held outside the database.
Job queue for long-running and high-volume work.
Dedicated vector search when pgvector no longer meets scale.
Visibility into agent activity, with durable workflow history.