From risk signal to decision
A detected risk is an input to a decision. The application policy determines whether the request may proceed, must be blocked, needs review or requires sensitive values to be removed.
AI runtime security
Pyrodit Guard
AI runtime security layer · Discuss your deployment
Define which AI requests and tool actions are allowed, which need review and how sensitive data should be handled.
Is this the right product?
- Built for
- Teams operating AI gateways, assistants and agents with access to sensitive data or tools.
- What it helps you do
- Evaluate requests and actions against policy, protect sensitive values and keep the decision trace.
- Its role in your stack
- The runtime protection layer. Scan Lab tests the system; Guard brings policy decisions and enforcement into its operation.
Scope & availability
Gateway, SDK and tool integrations are in development. Evaluation defines the policy boundary and checks how blocking, masking and service failures affect your application before enforcement is enabled.
- Starts with
- AI requests, outputs or tool actions with identity and policy context.
- Produces
- Policy decisions, required transformations and an enforcement record.
- Deployment
- Integration at a gateway, SDK or tool boundary, with explicit timeout and failure behavior.
Follow the work
Design the boundary before enforcing a decision.
A planned integration scenario: an assistant may send sensitive text to a tool. Shared detection and masking primitives support the design; end-to-end Guard enforcement needs integration acceptance.
Planned workflow · in development
Identify the action boundary
Choose the request, response or tool action to inspect. Include identity, permitted capability and the destination so the consumer policy has enough context to decide.
Example output
- Boundary context
- Actor, action, destination and the policy scope for the intended integration.
A runtime security layer that connects risk signals to your organisation’s rules. Define when to allow, block, mask or request review, and retain a record of the decision and its application.
01
Runtime integrations
Connect gateways, policy enforcement points, SDKs and adapters at request, response and agent-action boundaries.
02
Profiles & policies
Publish signed, versioned profiles and policy bundles, bind detectors, masking rules, workloads and resources, then promote them deliberately.
03
Decision engine
Resolve permit, deny, require approval or indeterminate outcomes from policy, detector signals and transform obligations with fail-closed controls.
04
Data protection
Apply masking policies and produce audit records for redact, hash, partial and replace transformations; keep vaulted tokenization as a controlled extension.
05
Protected operations
Register operations, expose tools, discover and bind MCP capabilities, and manage grants, delegations and executor bindings before side effects occur.
06
Evidence & egress
Record interactions, signals, decisions, coverage attestations and enforcement receipts, with health, alerts, emergency controls and secure egress policy.
Architecture & control
Signals first. Decisions with evidence.
Detection identifies a potential risk; your policy determines the response. Guard’s integration design keeps the signal, decision and enforcement record connected.
Protection at the boundary
Planned gateway, SDK, tool and MCP integrations are intended to apply masking, capability and approval rules before an agent action becomes a side effect. Their end-to-end enforcement acceptance remains deployment work.
Receipts and coverage
Keep the policy version, requester, risk signals, changed fields and final decision with the interaction record. This context supports incident review and investigation of data leaving the system.
Use cases
Enterprise challenges. Coordinated decisions.
Keep goods moving, production running and banking operations accountable. Explore workflows across business units, systems and approval boundaries.
Balance inventory across stores, warehouses and digital channels.
When campaign demand diverges from stock, evaluate store and online orders in one allocation plan. Balance availability, margin and logistics capacity.
Explore the workflow →Contain supply disruption before it stops production.
Assess a delayed critical component against plants, production schedules and customer commitments. Compare alternative sourcing, inter-site transfers and rescheduling in one decision file.
Explore the workflow →Coordinate payment incident response around business impact.
Connect a payment-channel disruption to transaction queues, reconciliation and customer commitments. Bring operations, technology and risk into one response plan.
Explore the workflow →Coordinate corporate onboarding through one review file.
Bring relationship managers, customer due diligence and operations into a shared case. Track legal entities, authorised representatives, missing evidence and review decisions together.
Explore the workflow →In practice
What happens in day-to-day use?
Explore the working steps, operational controls and evaluation boundaries behind the product.
How is Guard different from Scan Lab?
Scan Lab organises deliberate assessments and their findings. Guard’s product direction applies security signals at runtime, where a consumer policy owns the decision to allow, deny, transform or request approval. Shared detectors do not make the two products interchangeable: an assessment finding and an enforced runtime decision answer different questions.
What is already present in the masking foundation?
The shared masking layer defines versioned, organisation- and project-scoped policies. Rules bind detectors to fields and strategies such as redaction, hashing, partial masking and replacement, with priority and enablement controls. Audit lineage links the policy snapshot, rule and detector configuration or model artifact so a transformation can be investigated.
Which enforcement integrations should we evaluate?
Start by identifying the boundary to protect: application requests, model responses or agent tool actions. Then define the consumer policy, masking behaviour, evidence retention and response to an unavailable detector. Gateway, SDK, adapter and playground surfaces are currently planned; an end-to-end enforcement integration must be verified before it is described as deployed protection.
Works alongside
Give each product a clear responsibility.
Combine the capabilities your process needs. Define how products share context, permissions and results across your workflow.
Pyrodit Scan Lab
Challenge policies and detector changes in controlled assessments before accepting a runtime integration.
Pyrodit Agentic Runtime
Identify the workflow boundaries where an agent may create an external effect, then agree on policy, failure behaviour and evidence.
Build with Mindtro