Weekly review completed — 3 AWS accounts (production, staging, development). 🔴 HIGH: 1 drift. 🟡 MEDIUM: 3 drift. ⚪ LOW: 3 drift.
AGENT · CONFIGURATION AUDIT
Cloud configurations stay aligned to the security baseline.
Configuration Audit runs weekly reviews of the customer's cloud configurations (AWS, Azure, GCP). Compares against the declared security baseline, flags drift, proposes remediation actions. Consistent with public security frameworks (CIS Benchmark, NIS2, DORA).
Configuration Audit at work.
🔴 New S3 bucket in production configured as public. Contains files with references to corporate customers. Required action: block public access immediately.
The public S3 bucket: block now. The 3 medium drift go into next week's sprint.
Actions recorded. Remediation applied. Sprint tasks generated. Event traced for ISO 27001 audit.
Why it exists.
The cloud configurations of mid-large companies are complex: multiple accounts, multiple regions, dozens or hundreds of services (compute, storage, networking, IAM, monitoring). Security depends on the consistency of configurations with declared baselines. Drift is constant: configurations modified manually, new services not configured to standard, policy updates not propagated across all accounts.
How it brings the review to the security team's channel.
The operational problem is not the absence of tools — CSPMs exist — it is integrating the signal into the security team's operational flow. Manual weekly reviews are slow and depend on people's availability. Critical drift often surfaces only at an incident. Configuration Audit brings the review to the security team's channel at a declared cadence, with severity already classified, and proposed actions ready for the responsible person's decision.
Remediations are pre-approved and traced.
For low-risk remediations pre-approved by the security team, the agent applies the remediation with notification. For remediations on production or with operational impact, the agent proposes the action and the security lead decides. The auto-remediation rule is declarative.
Cloud security, DevOps, compliance: three perspectives on drift.
Cloud security lead (CISO)
Reclaims the time of weekly manual account reviews. The team's capacity concentrates on drift that requires judgement: the CISO does not read three hundred configurations — they read the structured picture the agent has already classified by severity.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
DevOps lead
Sees drift from baselines in a structured way. Remediation actions become tasks in the standard patching pipeline, not emergencies handled urgently outside normal processes.
Proposal no. 2024-081 In review
Missing disclosure
MiFID II art. · regulated financial instrument
Alt. 1 …in compliance with MiFID II and applicable supervisory provisions.
Alt. 2 …with full disclosure attached to the offer document.
Audit trace recorded · 14:31
Compliance lead
Has an inspectable trace of reviews for security audits (ISO 27001, NIS2 for energy/telco/public sector, DORA for banking). Querying the registry returns every drift identified, every decision taken, every remediation applied.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Sunday evening. The summary is ready for the CISO before Monday morning.
The agent is scheduled every Sunday at 20:00.
For a B2B SaaS company with three AWS accounts (production, staging, development), the agent is scheduled every Sunday at 20:00. It reads the configuration of the relevant services across all accounts. AWS API integration is delivered during the project by the Exelab team. It compares against the baseline declared by the security team (based on CIS Benchmark and internal company rules).
Seven drift items identified, classified by severity.
It identifies seven drift items. Three low: log retention manually reduced on three S3 buckets. Three medium: security group with open port, volume without encryption, IAM policy with excessive permissions. One high: new production bucket configured as public by mistake, containing files with customer references.
The CISO authorises the block and schedules the remediations.
The summary reaches the Slack channel on Sunday evening. The CISO authorises immediate blocking of the public bucket, schedules the three medium drift items for the week, accepts the three low items with a motivated note. The full event stays in the audit registry for ISO 27001 audit.
Configuration and technical resources.
The Configuration Audit rules are declarative. The customer's cloud security team defines the configuration baselines per service (based on CIS Benchmark, NIS2, internal framework), the severity thresholds for drift, the remediation rules (what is auto-remediable with notification, what requires manual approval). The rules live in the customer's repository, versioned.
Integration with cloud providers (AWS, Azure, GCP) is delivered during the project by the Exelab team via dedicated adapters that use the providers' official APIs with read-only IAM access (plus remediation actions configured for pre-approved cases). The access perimeter is declared and agreed with the customer's security team during delivery.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, tool-rate-limit
- Native channels
- Slack, Telegram, OpenAI-compatible HTTP
- AWS, Azure, GCP integration
- dedicated adapter delivered during the project (via cloud provider API with read-only IAM access + pre-approved remediations)
- Security baselines
- declarative, versioned, written by the cloud security team (compatible with CIS Benchmark)
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on historical configuration patterns
- Registry
- immutable, queryable with a standard SQL client
Frequently asked questions about the agent.
For low-risk remediations pre-approved by the security team (e.g. disabling public access on a newly created staging bucket), the agent can apply the remediation with notification. For remediations on production or with operational impact, the agent proposes the action and the security lead decides. The auto-remediation rule is declarative and configured by the team.
CSPMs (Prisma Cloud, Wiz, Lacework) provide cloud configuration monitoring as a dedicated service. Configuration Audit covers the same function but is integrated in Polyant as part of the customer's IT team, under the unified runtime governance. For customers already using a CSPM, Configuration Audit can work in aggregation (reading the CSPM output) or replace the review function for specific cases.
The typical pattern is 6-10 weeks. Discovery and baseline configuration 1-2 weeks, severity rule writing 2-3 weeks, integration with the customer's cloud providers 2-3 weeks, hand-off to the cloud security team 1-2 weeks.
The agent handles multiple accounts and different cloud providers in the same instance. Each account and provider has its own adapter; the weekly summary aggregates drift cross-account into a single picture for the CISO. The access perimeter configuration for each provider is agreed during delivery.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Configuration Audit would configure to the customer's case. Which cloud accounts, which security baselines, which reference frameworks.