Table of Contents
- The review in 30 seconds
- Why Salus exists
- The part I like most
- What Salus appears to do well
- The catch
- Salus pricing: what the numbers actually mean
- What makes me cautious about security and control
- What looks strong—and what still needs proving
- How I would test Salus
- Salus alternatives
- Who should actually use Salus?
- The funding context
- Final verdict
- Frequently asked questions
An agent can have valid credentials, call the right tool and still do the wrong thing. Observability tells you what happened afterward. Salus is trying to make the decision one step earlier—before the refund, booking or record change becomes real.
Salus is runtime authorization and policy enforcement software for consequential AI-agent actions.
My short take: Salus is a credible pilot for teams letting agents move money, change records or call external systems. Protect one consequential function in shadow mode, label the expected decisions and inject failures. Do not switch on enforcement until the team can explain every block, escalation and timeout.
This is Salus's real first-party homepage, captured on 27 October 2026—not a generated product mock-up.
The review in 30 seconds
| The question | My answer |
|---|---|
| What is it? | runtime authorization and policy enforcement software for consequential AI-agent actions |
| What is the interesting part? | Salus does not only block. |
| What would I test first? | A support team wraps one refund function and starts in shadow mode. |
| What is the biggest concern? | The policy layer becomes part of the production path. |
| How much does it cost? | Pilot $500/month; Partner $2,500/month; Enterprise custom; unlimited seats with agent and action-check limits |
| Who should shortlist it? | engineering and security teams deploying agents that perform consequential writes, financial operations, bookings, account changes or external communications |
Why Salus exists
Authentication answers who may call a tool. It does not prove that this particular action is supported by current evidence, within policy or appropriate for the workflow state. Salus sits at the execution boundary and returns allow, block or escalation decisions before the side effect runs.
In practical terms, it is trying to help teams:
- Inspect proposed tool actions immediately before execution
- Allow, block or escalate calls through versioned policy rules
- Run new controls in shadow mode before enforcement
- Return structured repair guidance to the agent
- Record decisions, evidence and provider outcomes for audit
The part I like most
Salus does not only block. It can return the missing evidence or correction an agent needs to repair the action, while preserving a decision receipt. That turns a guardrail from a silent wall into part of the agent’s recovery loop.
That is the idea that earns Salus a place on a shortlist. The rest of the evaluation is about whether the implementation can support it without creating a new operational problem.
What Salus appears to do well
Protected execution boundary
The SDK wraps the callable that performs the side effect or uses a decision API immediately before execution. Test that every path reaches the boundary, including retries, background jobs and alternate providers; one unwrapped route can invalidate the control model.
Shadow and enforcement modes
Shadow mode records what would happen without stopping the existing call, while enforcement blocks non-allow decisions. Replay representative traffic and prove expected allows and blocks before promotion. A shadow block is evidence about policy, not evidence that an action was stopped.
Versioned policies and approvals
Rules can inspect arguments and context, then allow, block or escalate. Review field names, units, ordering, defaults and policy ownership. High-risk actions need explicit no-match and timeout behaviour rather than an optimistic fall-through.
Decision receipts and outcomes
Salus records the rule path and evidence behind a decision and can attach the provider outcome after execution. That separation matters: authorization does not prove the backend succeeded. Test export, retention, redaction and whether incident investigators can reconstruct the complete chain.
Evals, replay and stress testing
The public documentation describes trace expectations and stress jobs for policy regression and adversarial discovery. Use a labelled set of dangerous and legitimate actions, then inject encoding, retry and provider faults so enforcement is tested beyond a curated demo.
The catch
The policy layer becomes part of the production path. A bad rule can block legitimate work, an incomplete rule can allow the dangerous case and a timeout can create an ugly choice between availability and safety. The product is only as trustworthy as its failure behaviour, policy review and latency under load.
That does not make the product a bad choice. It identifies the exact claim the pilot needs to prove. A polished demonstration is useful for learning the interface; it is not evidence that the difficult cases work.
Salus pricing: what the numbers actually mean
Salus lists a $500-per-month Pilot plan with 10 agents and 200,000 action checks, and a $2,500-per-month Partner plan with 50 agents and 1.5 million checks. Both include unlimited seats, shadow and enforcement modes, reasoning gates, provider completion checks and Incident Rewind, with different support levels. Enterprise is custom for unlimited agents and higher volume. The Pilot plan is month-to-month. Model cost is less important than blast radius here, but buyers still need overage, latency, retention and support terms in writing.
The published price is only the beginning of the cost. I would also model implementation, usage, storage, integrations, human review and the work required when something fails. When model or API consumption matters, the AI Token and API Cost Calculator can help turn expected volume into a range rather than a guess.
What makes me cautious about security and control
Salus sits on a consequential execution path. Its trust page states encryption in transit and at rest, workspace isolation, scoped roles, configurable retention and SOC 2 Type II work in progress. Confirm key management, runtime authentication, tenant boundaries, redaction, data minimisation, deletion, audit integrity, subprocessors, regional processing, incident response and the exact fail behaviour when the authorization service is unavailable.
I would request the current security pack and map every credential, data type, automated action and deletion path before production access. The important question is not whether the vendor has a security page; it is whether the purchased plan and proposed architecture satisfy the team's real boundary.
What looks strong—and what still needs proving
What looks strong:
- Acts before the side effect rather than only analysing it afterward
- Shadow mode supports a bounded path into enforcement
- Decision receipts separate authorization from execution outcome
- Public pricing and plan limits make a pilot commercially concrete
What still needs proving:
- A policy mistake or service outage can affect critical production work
- Public documentation currently centres on a customer-only Python SDK
- Teams must maintain labelled decisions and policy ownership
- SOC 2 Type II is described as in progress rather than complete
This is the useful dividing line between marketing and a buying decision. The strengths explain why the product is interesting. The unresolved points determine whether it is safe and economical for this particular team.
How I would test Salus
A support team wraps one refund function and starts in shadow mode. It replays labelled calls covering valid refunds, missing order evidence, amount thresholds, duplicate requests and provider timeouts. Reviewers compare expected and actual decisions, measure added latency and approval delay, then enable enforcement only for that function while keeping a rollback path.
I would include normal work, edge cases and known failures, then record completion, serious errors, human corrections, latency and full cost. Preserve the same input set so another product can be tested on equal terms. The AI Tool Chooser can help turn those requirements into a consistent shortlist before the pilot starts.
Salus alternatives
| Consider | When it makes more sense |
|---|---|
| HumanLayer | human approval and escalation are the main requirement |
| Permit.io | application authorization and policy-as-code are broader than agent actions |
| Lakera Guard | prompt and model-input security matter more than tool execution |
| Sentrial | behavioural monitoring and diagnosis after agent runs lead the decision |
| A custom policy gateway | the action set is small and the team can own evaluation, audit and uptime internally |
The feature labels may look similar, but the operating model can be completely different. Test the closest two options on the same work rather than comparing screenshots and plan names.
If the shortlist is already becoming another stack of overlapping subscriptions, our guide to why companies pay for too many AI tools explains the consolidation questions to ask. For a broader selection framework, which AI tool should I use for my business? separates useful fit from feature-count noise.
For adjacent examples, read our Sentrial review and Cua review.
Who should actually use Salus?
Salus makes the most sense for engineering and security teams deploying agents that perform consequential writes, financial operations, bookings, account changes or external communications.
It is a weaker fit for read-only assistants, low-risk prototypes, teams that cannot maintain explicit policies or stacks that require a production SDK language Salus does not yet support. In that situation, a narrower product, an existing platform feature or a better manual process may solve the problem with less integration and governance work.
Software solves an operating problem; it does not automatically make a SaaS company discoverable. Teams that also need buyers and AI answer engines to find their product can review our AEO and AI visibility service as a separate acquisition decision.
The funding context
Salus is listed by Y Combinator in the Winter 2026 batch. YC’s standard deal invests $500,000 in accepted companies. No company-confirmed cumulative funding total was found in the reviewed primary sources, so this review labels funding as the YC investment minimum only.
Funding can help a company build the expensive parts of the product. It does not establish reliability, security or customer fit, so it is context—not part of the verdict.
Final verdict
Salus addresses a boundary that ordinary agent observability does not: whether a proposed action should execute now. Its shadow-to-enforcement workflow, deterministic policies, repair responses, decision receipts and public pricing create a strong evaluation path. The trade-off is serious operational responsibility. Buyers must prove policy accuracy, fail-closed behaviour, latency, approval handling and SDK fit before placing it in a critical execution path.
My recommendation: Salus is a credible pilot for teams letting agents move money, change records or call external systems. Protect one consequential function in shadow mode, label the expected decisions and inject failures. Do not switch on enforcement until the team can explain every block, escalation and timeout.
Frequently asked questions
What is Salus?
Salus is runtime authorization software that evaluates proposed AI-agent tool actions before the underlying side effect executes.
How much does Salus cost?
Salus listed Pilot at $500 per month and Partner at $2,500 per month when checked on 27 October 2026. Enterprise pricing was custom.
Can Salus run without blocking actions immediately?
Yes. Shadow mode records what a policy would decide while the existing tool still runs, allowing teams to validate rules before enforcement.
How much funding has Salus raised?
Salus is a Winter 2026 YC company and passes YC’s $500,000 standard investment threshold. We did not find a company-confirmed cumulative total.
Was this Salus review hands-on?
No. This is a research-based first-look review using official public evidence. We did not test an authenticated Salus workspace or connect production data.
Did Salus pay for inclusion?
No disclosed commercial relationship or payment influenced this review, and no numeric rating was assigned.
Tolu S.
Operations Lead, AI Search & GEO
Leads operations for AI search visibility and generative engine optimization (GEO) campaigns.
