Our approach

Access is a capability.
Authority is a boundary.

We’re building a way to evaluate whether customer-facing agents respect the permissions and tenant boundaries your application intends.

Authorization assurance focus

OUR FOCUS

Keep customers apart.

tenant_a !== tenant_b

Evaluate whether an agent can cross the customer-data boundaries your application relies on.

  • Customer-facing agents
  • Cross-tenant access scenarios
  • Intended isolation model
OUR FOCUS

Keep authority in scope.

agent.scope ⊆ user.scope

Look at what an agent can read and do in the context of the person who initiated the request.

  • User and role context
  • Read and write permissions
  • Tool-level actions
OUR FOCUS

Make findings actionable.

reproduce → remediate → retest

Connect a boundary failure to evidence an engineering team can investigate and verify after a fix.

  • Reproducible scenarios
  • Expected vs. observed behavior
  • Remediation verification

Evidence over assumptions

A finding should
tell the whole story.

Which user initiated the request? Which tenant should be in scope? What did the tool read or change? A useful finding connects those details to the expected permission model.

These synthetic examples illustrate our direction. They are not results from a live product or customer evaluation.

What useful evidence looks like
Fuzz / authorization evidenceIllustrative
TENANT BOUNDARY19 SEC / CONCEPT SIMULATION

Tenant boundary. The returned record belongs to a different customer. Actor: support-agent. Expected scope: tenant_a. Tool: read_customer_record. Observed result: tenant_b. Finding: AUTHORIZATION_MISMATCH. This is an illustrative workflow with American narration and optional English captions.

Start with a bounded question

Make evaluation
specific.

We expect initial evaluations to be scoped around an agent, a permission model and a set of agreed boundaries. Requirements and availability will be discussed directly while we’re in stealth.

01

Map the context

Identify the initiating user, tenant, tools and application-side authorization checks.

02

Define expected behavior

Agree what must be allowed, denied and escalated for approval before evaluating the agent.

03

Evaluate safely

Use an authorized test environment and synthetic or approved test data. Establish limits and stop conditions.

04

Close the loop

Review evidence with the team, address the underlying permission boundary and retest the original scenario.

Focused today. A broader direction ahead.

Our initial focus is authorization and tenant isolation. Continuous regression testing and runtime enforcement are future directions to explore, not promises of current availability.

Let’s connect

Building an agent that can take action?

Tell us what you’re working on. Help shape what comes next.

Join our waitlistInvestor contact