Product details

Behind the scenes

How the parts work together

01/Gateway

Request checks

Checks requests from connected tools. MCP is pilot-tested. OpenAI and Anthropic support is experimental.

02/API

Shared rules

Manages rules, approval requests, and activity records.

03/Sentinel

Tool discovery

Finds local tool settings. It does not intercept running tools. Kernel monitoring is (planned).

04/Cortex

Content checks

Flags known harmful instructions. Advanced detection is experimental.

05/Console

Your dashboard

Review activity, change rules, and approve or deny requests.

Your options

Choose what happens next.

Allow a request, stop it, or ask a person. Paart records the decision.

Allow

Let the request continue.

Observe

Let it continue and flag it for review.

Hide tool

Remove a tool from the available list.

Remove data

Remove matched sensitive information.

Ask a person

Hold the request for a person’s decision.

Block

Stop the request and return an error.

Stop session

Stop this session at the Paart gateway.

When rules conflict Stop session Block Ask a person Remove data Hide tool Observe Allow

Supported connections

Check whether your tools can connect.

Connection

Status

Notes

MCP (JSON-RPC)

Pilot-tested

Tested in the pilot with four threat scenarios.

OpenAI function-calling

Experimental

Experimental. Not yet verified in the pilot.

Anthropic tool-use

Experimental

Experimental. Not yet verified in the pilot.

Generic HTTP / custom

Planned

Custom connections need development.

Use cases

Where Paart can help.

Support depends on your connection and rules. Each example is marked tested or experimental.

01 Unapproved tools

Spot unfamiliar AI tools

Review first-seen agents and choose whether to register or block them.

Observediscovery · pilot-tested · you choose what to block

02 Data protection

Protect sensitive data

Find and redact recognizable secrets and personal information in connected requests and responses.

Remove databuilt-in rules · stable

03 Prompt injection

Flag harmful instructions

Recognize known attack phrases. Pattern checks have limits and will not catch every attempt.

Blocksemantic engine · experimental

04 Code assistants

Check risky code actions

Optional rules flag dangerous commands such as rm -rf /, or scripts downloaded and run with curl … | bash.

Blockcode-assistant rules · stable

05 Supply chain

Notice changed tools

Compare tool definitions and flag changes that need review.

Hide toolchange detection · pilot-tested · re-approval is optional

06 Privilege escalation

Spot unusual activity

Flag unusual chains of requests, such as a chatbot reaching for a deployment tool.

Observeactivity checks · pilot-tested · blocking is optional

07 Compliance

Support security reviews

Use rule packs to address known AI risks. Their framework mappings do not constitute certification.

Observerule packs · stable

08 More connections

Check integration support

Your client must support routing through Paart. Contact us to check compatibility with a specific product.

Remove dataprotocol-agnostic · experimental

09 Governance

Ask before sensitive actions

Configure a rule to Ask a person. Review it under Console › Approvals; approve or deny the request.

Ask a personapprovals workflow · stable

10 Inventory

Keep an agent inventory

Review registered and unregistered tools. Suspicious and malicious labels come from experimental sensors.

Observeinventory · pilot-tested

11 Action rules

Set boundaries for actions

Choose what a connected AI tool may do. Check what it requests against your rules and record the outcome.

Blockpolicy engine · stable

12 Incident response

Stop a risky session

Optional risk rules can stop a session at the gateway. Credentials elsewhere are not revoked.

Stop sessionrisk scoring · experimental · auto-quarantine is opt-in

In your dashboard

A person gets the final say.

A refund rule can Ask a person before money is returned. These are illustrative examples.

console › approvals

ILLUSTRATIVE EXAMPLES

Pending approvals 3

Pending

Customer assistant [registered]

Issue a refund · approval needed · policy Refunds need approval

2m ago

Pending

Coding assistant [registered]

Install a software package · Package source needs review · rule Review package sources

14s ago

Pending

Connected tool [registered]

Tool changed · Search now requests more access · policy Review changed tools (optional)

just now

Illustrative examples. Approval rules require configuration; re-approval after a tool change is optional.

Performance

Measured in the lab.

Engine tests only. Network, database, and external detection delays are excluded.

1.82 milliseconds Engine check time (p99)

1,000 events per second · 10-minute test

Lab setup: Apple M1 Max, 100 sessions, 599,986 samples. Results vary by deployment.

p50

287 µs

p95

708 µs

p99

1.82 ms

max

22.68 ms

In-process benchmark. Ask us for the methodology when evaluating a pilot.

Starting rules

Start with rules for your use case.

Choose a rule pack, then configure and test it against your own workflow.

01 / Chatbots

Public-facing assistants

→Attempts to bypass instructions
→Requests for hidden instructions
→Secrets in responses
→Impersonation attempts
→Unnecessary personal data collection

02 / Coding tools

Coding assistants

→Destructive commands
→Exposed credentials
→Unexpected file access
→Untrusted package sources
→curl … | bash patterns

03 / Customer service

Customer-service assistants

→Sensitive customer data
→Approval before refunds
→Access to another customer’s data
→Attempts to pressure the assistant
→Approval before large data exports

Built on

Built on the open-source MCPIDS project.

Paart adds the dashboard, deployment tools, and controls for teams. Paart itself is a proprietary product.

Rules Tool definitions Change detection Risk checks Activity patterns Detection rules