Shield

In development · Waitlist / pilot interest welcome

The problem

Once AI can act, a bad proposal can become a real business risk.

When AI agents can access email, data, tools or business systems, a good model response is no longer enough. Organizations need control over which components are trusted, where data may go and which actions are actually allowed.

Teams use different models and tools.

Without central control, it becomes unclear what was released and which version is actually in use.

An agent can do more than generate text.

If it can send email, change data or call other systems, a bad proposal can become a real business event.

Sensitive data can reach the wrong model.

Not every piece of information may be sent to every model or provider.

Tools can contain problematic instructions themselves.

A tool or its description must not become trusted simply because a model finds it convincing.

Evidence is often missing afterwards.

Who was allowed to do what? Which version was released? Which rule made the decision?

The solution

Shield separates model proposals from real authority.

Models, agents, tools and software receive known identities. Before a controlled AI request is made or a proposed action is considered allowed, Shield checks the rules defined for that context.

Data can be classified, known secrets detected and risky content treated as a security signal. Proposed actions are structured and checked against the intended permissions.

The model may propose an action. The security decision is not made by the model.

What Shield handles

Make trust visible. Keep authority controlled.

Identify software and artifacts

Identify software through actual content and recorded provenance rather than filenames or tags alone.

Register models, agents and tools

Manage released components with explicit identities and versions.

Version security rules

Change rules under control and retain which version applied to a decision.

Control AI requests

Check which model may be used and whether a request stays within intended boundaries.

Classify data

Assign protection levels before information is sent onwards.

Detect known secrets

Detect common credentials and secrets deterministically without claiming complete coverage.

Mark untrusted content

Treat web content, email, tool output or model responses as untrusted inputs and consider risk signals.

Check proposed actions

Convert tool calls into structured requests and evaluate them against concrete rules and parameters.

Document decisions

Keep important allows and denials as traceable evidence.

Measurement

Measurement to follow.

For Shield the negative proof comes first: tenant isolation, policy determinism, replay protection, approval binding. Performance numbers after that — and only with reproducible evidence.

Product boundaries

In the current product state, Shield decides whether a proposed action is allowed. Execution of that action is not yet part of this product state.

Shield is not antivirus, EDR or a traditional CVE dashboard.

Prompt-injection and secret detection are security signals, not completeness guarantees.

A language model is never the final security authority.

Next step

Where should AI be allowed to act in your systems?

Describe the concrete AI or agent workflow and the systems involved. From there, we can determine where Shield can create a controlled boundary.

Discuss Shield →