Product information security, declared article by article.
Polyant has ten built-in controls that activate before, during, and after every agent decision. The security configuration lives in the runtime, not in a separate product. The customer decides where the software runs, who inspects the code, and how the audit registry is read.
Ten controls that work together on every decision.
An agent decision passes through three phases: input, tool, output. At each phase, specific controls activate according to the instance configuration. The compliance lead sees everything, rule by rule, in the audit registry.
prompt-injection
13 regex patterns in Italian and English that intercept prompt-injection attempts in the input text.
message-length-limit
Blocks input messages above the threshold configured per instance.
topic-guardrail
Blocks categories of topics configured per instance.
tool-domain-filter
Allowlist and denylist of domains with wildcards applied to tool calls that reach the web.
tool-rate-limit
Per-minute and per-conversation rate limits on each tool.
internet-access
Disables, per instance, the tools that reach the public web.
tool-param-validator
Validates the parameters of tool calls against the declared JSON schema.
credential-detector
7 patterns for API key, JWT, AWS keys, PEM, and connection strings that block credentials in cleartext from leaving in the output.
system-prompt-leakage
Canary tokens and blocked phrases that prevent the system prompt from leaving the runtime.
pii-detector
Detects email, phone, fiscal codes, IBAN, and structured personal data in the output before delivery to the channel.
Every control has three modes: block, warn, and log. Three policies are preloaded at startup and are immutable: prompt-injection, credential-detector, and system-prompt-leakage. The others are configurable by the customer's team.
Each agent is an isolated instance, with secrets encrypted at rest.
Each agent deployed by the customer is an instance with its own UUID, its own configuration, its own secrets, and its own channels. The per-instance secrets, including API keys and integration credentials, are encrypted with AES-256-GCM.
The master key lives in a runtime environment variable and can be managed with an external KMS or HSM in enterprise deployments.
Isolation is at the database level: configurations from one instance are not visible to the others.
What the software does, what the customer does, what Exelab does.
The Polyant security model clearly defines responsibilities across the different adoption methods.
Self-host
The customer handles configuration, patching, backup, monitoring, and audit prep.
Exelab professional services
Exelab supports delivery and operational handoff.
Exelab managed
Exelab handles runtime, monitoring, and operations in accordance with the SLA profile.
On the customer's systems, on the customer's cloud account, on Exelab-managed infrastructure.
Polyant runs as a Docker container on any infrastructure. The customer chooses where to deploy it and who operates it.
On the customer's systems
Docker container on the customer's Kubernetes or internal virtual machines.
On the customer's cloud account
Docker container on the customer's AWS, Azure, or GCP account.
On Exelab-managed infrastructure
Docker container on Exelab infrastructure in an EU region.
The registry lives inside the customer's database.
Every runtime decision is written to dedicated PostgreSQL tables inside the customer's database. The compliance lead can query the registry using any standard SQL client, even months later.
From a technical conversation to the first governed agent in production.
Technical conversation with the Exelab team to qualify the security model on the customer's case, or deeper dive on the runtime architecture in the technical documentation.