The whole of Prizma, through one defence workflow.

Visibility and detection

See what is threatened, and where the evidence comes from.

A resource inventory shows which applications, endpoints and actions are covered. Authenticated sources connect network and Windows events, DNS and email signals, HTTP request patterns and departures from normal behaviour. Event and session correlation helps the team examine a broader incident and summarize a suspected campaign across sources, with uncertainty clearly marked.

Behavioral assessment may indicate automated, human or undetermined activity, with uncertainty displayed. A change in speed or suspected use of AI does not determine access rights. Prizma does not need to identify the person behind an attack to constrain an unauthorised action on a controlled path.

AI requests and data

Define what AI may read, process and send.

Supported requests and responses, including streamed responses, pass through content inspection and transformation rules. Redaction and secret-exposure controls are applied with data provenance and markers tracking permitted flows. Combining or summarizing content does not erase restrictions attached to its sources. Revealing previously protected data requires appropriate approval.

A document, tool result or another agent's message can provide data; it cannot grant authority by itself. Each supported model and provider has verifiable provenance and identity, named formats, permitted destinations and call limits. An unavailable model does not justify silently switching to an unapproved provider.

Agent permissions

Give the agent a task with boundaries that hold at execution.

The task binds a trusted issuer, organisation, purpose, resources, tools, recipients, duration and limits. A catalog specifies the exact tool version; an action proposal identifies the concrete arguments and target. Permission is checked again immediately before execution.

An isolated executor holds the minimum necessary privileges. Through a controlled broker, it receives short-lived credentials for a specific purpose; the agent does not receive its privileged credentials. Rules apply to the actual connection and destination. Deployment closes alternative credentials and execution paths that could bypass this control.

Delegation can narrow authority. Revocation and shared limits apply across related agents, with atomic accounting of consumption, and survive restarts. Notes and other indirect communication channels retain provenance and do not create new permission.

Response

Respond precisely where you have authority.

The detection rule version is kept separate from the policy authorizing a response. A catalog defines a finite set of permitted actions and their reversal procedures: rejecting a specific request, restricting a session or isolating an eligible endpoint through a supported network or endpoint control. Reversing a restriction cannot undo consequences that have already occurred.

Each action passes a common check of its target, scope, duration, authority and consequences, including protected resources and Prizma's own components. Dry-run mode does not enforce the restriction and is clearly separated from a real response. Policy determines automatic execution or appropriate human approval. The console distinguishes proposal, approval, submission, acceptance and verified effect.

Durable state limits unintended repetition. After a timeout or failover, state is reconciled with the observed result before another attempt. Independent observation checks both the response target and the essential service's operation.

Continuity during an incident

A defence must account for the consequences of its decision.

A dependency map, information freshness and protected roles show what a broad response could interrupt. If the consequences are insufficiently known, the system gains no authority for wider isolation; the operator sees the uncertainty and narrower permitted choices.

Prizma has boundaries too. An independent operator channel can constrain its response and enable recovery when it is faulty or compromised, without relying on its executor's cooperation. Preserving services also depends on the customer's agreed infrastructure and responsibilities.

Recovery and availability

Prepare the return to work before it becomes urgent.

Consistent data backups, restore verification and a separate recovery location form the plan's foundation. Failover maintains a single authorised response executor. Data-loss allowances and time to restore service are tracked.

Loss of storage, power or a site also requires spare resources, physical infrastructure and responsible people. The plan connects their work with verification of restored data and system operation. A saved archive alone does not establish successful recovery.

Investigation and evidence

Preserve a story the team can verify.

A timeline connects events, identities, sessions, decisions, approvals, actions and outcomes. History search, reports and permitted CSV/STIX exports support investigation and exchange. Case management in the broader platform adds an accountable analyst, notes and false-alarm adjudication.

Event receipt is confirmed only after the required durable storage point. A journal and outbox retain failed attempts, while history replay preserves consistency. Evidence packages include independent checkpoints and completeness verification; provenance, authenticity and permission to export are checked separately.

Decoys and intelligence sharing

Notice interaction with a resource that has no legitimate business use.

Registered decoy resources, login surfaces and an assistant create controlled observation points. Their lifecycle, rotation and bounded adaptation track coverage. Records preserve exactly what a decoy callback or interaction chain establishes; contact with a decoy is not proof of access to a real account.

Approved indicators can be exchanged between authenticated organisations under privacy rules. Another organisation's indicator enters as information to assess. It does not transfer that organisation's authority to respond automatically or establish a coordinated campaign by itself.

Configuration and notifications

Know which rules are active, and how far an alert has travelled.

Onboarding and configuration distinguish desired, saved and active state. The operator sees conflicting edits, required restarts and the actual readiness of the relevant component.

Supported webhook, SIEM and email channels show sending attempts, transport acceptance, errors and controlled retries. An accepted message is not automatically a read message; the channel state stays clear.

People, access and privacy

Give each person the visibility and authority they need.

Named accounts, secure sessions and passkey sign-in connect to identity lifecycle, revocation and roles. A supported identity integration verifies access on the server. Events and actions are bound to an authenticated source, participant, organisation and resource.

Organization isolation, minimized collected fields, retention periods and permitted masked exports protect data boundaries. An accessible workspace in Serbian and English supports review and decisions. Retirement of the legacy interface and a fallback view preserve access control and a safe return path.

Integrations, delivery and support

Deploy protection you can maintain.

A support matrix names versions, installation modes and responsibilities across application security, network controls, endpoint security, identity, records and recovery. Secure connections and the placement of management and execution components define trust boundaries.

An external attacker's model does not need to pass through Prizma. Protection is enforced on the organisation's side through deployed controls. Application patching and workload isolation remain responsibilities of the customer and its systems, connected to the deployment plan.

Verifiable release provenance and signing, repeatable installation, controlled upgrades, rollback and named support accompany the product in operation. Metrics and independent monitoring report loss of a service or source. An integration change or failure of a required check withdraws the corresponding support designation until evidence is restored.

Demonstrating protection

Measure protection and successful work.

A code-assessment result is bound to the actual tool, model, version, execution and target. VVAH integration enters when qualified; a SARIF format or demonstration output is not itself a performed assessment.

The validation plan uses an isolated laboratory with an outer access boundary and an independent observer. It compares existing protection, added Prizma monitoring and enforced controls. Each unauthorised attempt is paired with a corresponding legitimate task, checking both effect and continued work. Acceptance leads to a limited rollout with an agreed rollback path.

Final institutional, adaptive-attack and outage tests remain ahead and require separate approval.