Cyber defence for your data, business systems and AI agents.
When someone misuses access or an AI agent attempts an unauthorised action, Prizma brings the evidence and response together. One workspace for external defence and control of your own agents — with checks on whether the restriction took effect and legitimate work can continue.
Prizma is in development. Explore the capabilities we are building.
The problem
Employees handle requests through a portal. An AI agent prepares a confidential report. The access that enables work can be misused from outside or through an unauthorised internal agent action.
The team must understand what is at risk, restrict the specific access and check the consequences. Sending a blocking request does not establish that access stopped. A broad restriction can interrupt other people’s work.
Prizma connects those decisions in one workflow: from the signal and authority to the observed effect and continued work.
Published reports describe both attackers’ use of AI and agents crossing evaluation environment boundaries. Read the sources and circumstances of those cases.
How it works
Follow one case: suspicious access to a business portal. Choose a step to see what the team learns, decides and verifies.
01 / 05 · Business portal example
A suspicious session attempts to reach confidential records. Prizma connects the signal to the account, evidence and business portal.
The team gets context for its decision, including a clear view of missing information.
02 / 05 · Business portal example
Policy defines the specific session, duration and required approver. A document or model proposal cannot grant authority.
The response has a known target and boundaries. Wider isolation requires a review of the consequences.
03 / 05 · Business portal example
The permitted action is sent to a supported access control. Acceptance of the request is recorded separately from evidence that it worked.
The team knows whether the action was requested, accepted or failed — and what still needs checking.
04 / 05 · Business portal example
Separate checks observe the restricted session and access for employees who need to keep working. Missing evidence leaves the outcome unconfirmed.
Two answers: was the access restricted, and does legitimate work still succeed?
05 / 05 · Business portal example
The case connects events, decisions, accountable people and the recovery procedure. Restoring data is followed by a check of the required service.
The incident closes against verifiable outcomes and agreed acceptance criteria.
An example of how Prizma is designed to work.
Three situations at work
Prizma connects defence against external access, boundaries for internal agents and control of its own response. Choose a situation.
The work being protected
Employees handle customer requests. A misused account attempts to reach data it is not entitled to access.
Connect suspicious activity to the account, evidence and affected service.
With the required authority, constrain the specific access through a supported control.
Check the effect of the restriction separately from access for employees continuing their work.
Essential work can continue while the specific suspicious access is addressed.
The work being protected
An agent is preparing a confidential report. A document contains a hidden instruction to send it to an external address.
Document content is input to the task, not a source of new authority.
Check the action, data and recipient before tool use; refuse the unauthorised transfer.
Track the permitted task separately. Another agent or a restart cannot expand permissions.
The organisation retains control even when someone else has influenced the model’s decision.
The work being protected
A suspicious trace leads to the employee sign-in server. Isolating it could interrupt access to essential services.
Check service dependencies and information freshness before a broad action.
When consequences are uncertain, show the uncertainty and narrower permitted options.
An independent operator can constrain Prizma’s response; recovery requires verification of service.
Control also applies to Prizma itself, with clear accountability for keeping work moving.
Planned capabilities shown with test data.
The workspace
The team sees the affected service, the reason for concern and available evidence. The response shows whether it has been requested, accepted or verified to have taken effect. A separate view shows the essential service's state.
Proposed interface shown with test data.
A closer look
A closer look
A closer look
Value
In the same case, the team sees why activity is suspicious, what it may do and what the response actually achieved. The service owner sees a separate answer: can essential work continue?
Prizma connects its own controls with supported systems in the organisation. The agreed scope includes software, named integrations, implementation and support.
Value is checked in actual work: time to an explained decision, an effective restriction, successful permitted tasks and deployment and maintenance hours. Comparison with the existing workflow should establish where Prizma brings value; improvement percentages are not assumed.
PRIZMA / 13
DATA / A LONGER HORIZON
Some data must remain confidential far beyond a single incident. Post-quantum readiness in the target Prizma platform connects cryptographic visibility, migration priorities and verification of protected business workflows.
Post-quantum readiness and research ↗︎
WEF 2026: the case for post-quantum preparation. Prizma has no WEF partnership or endorsement. Sources and dates ↗︎
Business secrets, health records and government information can remain sensitive for years.
Quantum risk to cryptography calls for preparation before a possible breakthrough.
Prizma’s existing development direction connects visibility, supported migration and business-workflow verification.
Deployment
Together, define data, permitted actions, accountable people and success measures. The first supported release has a precise scope and named integrations. The full platform includes external defence and internal agents.
The deployment plan shows where Prizma observes activity, where it constrains actions and what remains the customer's responsibility. It connects to selected application, network, identity and endpoint systems.
The initial development direction is management hosted by the customer on Linux with selected Windows/Linux endpoints. Versions and integrations require support validation.