Solomon Agentic AI Platform · SaaS and PaaS
Autonomous agents, deterministic guardrails.
The multi-tenant platform behind every Solomon product. It ingests your telemetry, detects threats and lets AI agents investigate and respond, while every action they propose first passes a deterministic layer of 10,000+ YARA and Sigma rules.
- proposedsupervisor → revoke_iam_session · svc-deploycontain
- sigma2 rules matched · session token replay · highpass
- tiercontainment needs tier 2 · tenant max tier 2pass
- grantEd25519 · single-use · bound to this action and targetsigned
- proposedsupervisor → kill_process(pid=4242) · web-03destroy
- yara1 rule matched · /tmp/.cache/kworkerdpass
- tierdestructive needs tier 3 · tenant max tier 2hold
Illustrative. Hosts, paths and ids are fictional; the order of checks is the platform's.
By design
- YARA and Sigma rules gating agent actions1
- 10,000+
- lower AI cost per investigation2
- 92%
- autonomy tiers, capped per tenant3
- 4
- longest life of a single-use approval grant4
- 300 s
- 1YARA and Sigma rules applied in the Platform's deterministic layer (owner-confirmed, 19 Oct 2026).
- 2VIntercept proprietary multi-model routing vs blind model calls, median of 100 tickets, answer quality held at 100%.
- 3Autonomy tiers, from full human approval to full auto-remediation: Solomon_Platform src/agents/autonomy.py. The tenant's configured maximum is a hard cap no alert can exceed.
- 4Longest life of a signed remediation grant: Solomon_Platform src/services/remediation_grants.py (REMEDIATION_GRANT_TTL_S). Each grant is single-use; replays are refused.
Capabilities
AI that reasons. Rules that decide.
Language models are good at investigating and bad at being predictable. Solomon lets the agents do the analysis and keeps the final say on any action with rules, signatures and, where policy requires it, a human.
Multi-tenant by construction
- One tenant is one identity organization with its own database, streams, storage, vector memory and secrets
- The tenant comes only from a verified token claim, never from a header or a request body
- Run it as SaaS, or build on it as a platform (PaaS) through the same gateway and SDKs
Ingestion and detection
- Cloud audit logs, identity, EDR and endpoint telemetry stream in and are normalized per tenant
- Sigma rules run in a streaming engine as events arrive; YARA rules run on the endpoints
- A tenant's custom rules apply only to that tenant and can never replace a global or another tenant's rule
Autonomous agents
- Triage, supervisor, identity and hunting agents analyze every alert end to end
- Each alert gets an autonomy tier from model confidence, rule severity and past accuracy
- The tenant sets the ceiling: no alert can act above the tenant's maximum tier
A deterministic layer under the AI
- Every action an agent proposes is checked against 10,000+ YARA and Sigma rules first
- Destructive actions, such as killing a process or quarantining an instance, need the highest tier
- Whatever falls outside policy goes to a human, on the console or on Solomon XGuard
Signed policies and commands
- Policies and every remediation command are signed with Ed25519 over RFC 8785 canonical JSON
- The eBPF Client verifies each signature against public keys it pins before it acts
- A command is only ever signed for the tenant it came from
Identity and model gateway
- Single sign-on for every portal; service calls use the JWT bearer grant (RFC 7523) with a key per tenant
- Tokens are checked against live keys with the algorithm pinned, and fail closed
- All model calls go through one gateway that injects provider keys, so no service holds them
Multi-tenancy
Every tenant on its own.
Tenants do not share a database with a tenant column. Each one gets its own database, event streams, lakehouse, vector memory and secrets, created when the organization is created and archived, not deleted, when it leaves.
The same isolation serves both ways of using Solomon: as SaaS through Solomon SOC, or as a platform your own applications and agents call through the gateway with SolomonPy and SolomonJS.
- Identity
- Its own organization; tenant id taken from the verified token only
- Database
- Its own Postgres database and login role
- Streams
- Its own Kafka topics, from normalized events to risk alerts
- Lakehouse
- Its own bronze, silver and lakehouse buckets, as Iceberg tables
- Memory
- Its own vector database, hybrid keyword and semantic search, PII scrubbed first
- Secrets
- Its own Vault paths for database and integration credentials
- Teardown
- Storage archived, never hard-deleted
Signed control
Every command signed. Every signature checked.
Every policy file and every remediation command the platform sends to an endpoint carries an Ed25519 signature over canonical JSON. The eBPF Client checks it against public keys it pins. In enforce mode it refuses anything unsigned or tampered with; in audit mode it raises a tamper alert.
Approvals work the same way. A remediation runs only with a single-use grant bound to the tenant, the agent, the exact action and its parameters, and the identity of whoever approved it. The private keys stay in Vault or AWS KMS; services ask for a signature and never hold the key.
SOLOMON-COMMAND-SIG-V1kind=commandtenant_id=382530872617730061agent_id=web-03key_id=solomon-policy-2026q4command_id=cmd_7f3a91issued_at=1792310400expires_at=1792310700sha256=9c1e…d04b
Solomon platform
The rest of the loop
- Kernel actsSolomon eBPF ClientKernel-level EDR and CDR, microsecond containmentExplore
- Agentic investigationSolomon SOCAgentic SOC: full investigations, with evidenceExplore
- Correlate and remediateSolomon OmniMeshConnect, correlate and remediate across your stackExplore
- Human in the loopSolomon XGuardMobile human-in-the-loop approvalsExplore
Let’s stop the swarm, together.
Run Solomon against your own workloads in a guided pilot. We’ll show you the kernel log, the investigation and the approval, on your infrastructure.