PRE-COMMIT BLOCK — Repository: backend-api, branch: feature/auth-refactor. Credential in plain text found: file config/test.env, line 23. Format consistent with a payment service API key. Severity: critical. Fix: move it to the company vault and reference it with process.env.PAYMENT_API_KEY.
AGENT · SECRET DETECTION
Credentials in plain text in repositories are found before the attackers find them.
Secret Detection scans the customer's repositories for credentials in plain text: API keys, access tokens, passwords, private certificates, connection strings. It activates on every new commit (pre-commit hook) and in a full daily repository scan. Immediate alert to the security team.
Secret Detection at work.
Fixed. Moved to the vault, updated the config file. Recommitting.
Commit authorised. No credentials in plain text detected. Event recorded in the audit log.
Why it exists.
Credentials in plain text in repositories are one of the most common security risks in software-development companies. A developer accidentally commits a file containing an API key, an access token, or a database password; the file lands in the repository, accessible to anyone with access to the project. Exposed credentials can be used for real attacks.
How it works on two fronts.
Pre-commit hook: activates at commit time, scans the diff for credential patterns in plain text, blocks the commit with a structured message indicating the pattern found and proposing the fix (environment variable, company vault, external config file). Full daily scan: runs on a daily schedule across the entire repository to find residual credentials from past errors that the pre-commit hook did not catch.
The decision stays with the team.
The security team decides how to handle the incident (revocation of the exposed credential, rotation, notification to the customer of the compromised service). The pre-commit block is structural — it prevents exposed credentials from reaching the remote repository.
Three technical functions that change the way credentials are handled.
Information security manager
Reclaims the time previously spent on manual repository reviews. Automated scanning covers the volume.
10 active controls
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
DevOps lead
Sees a reduction in security incidents caused by exposed credentials — one of the main sources of compromise in mid-to-large companies.
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
Developer
Gets immediate feedback at commit time, not weeks later. The learning curve on correct use of vaults and environment variables accelerates.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · code within the customer's perimeter
A blocked commit, a rotation, two fronts working together.
The commit blocks on the critical pattern.
For a B2B SaaS company with 25 developers, the agent is integrated with the GitHub repository via webhook and a daily schedule. A developer commits a change that includes a test configuration file containing the API key of a third-party service. The pre-commit hook fires. The agent scans the diff. It identifies the pattern: a string formatted as an API key. The pattern is classified as credential in plain text, critical severity. The commit is blocked with a structured message: file and line found, recommended fix.
Vault, reference, recommit.
The developer moves the credential to the project vault, updates the file to reference the vault, recommits. The commit goes through.
Residual credentials from the past surface in the log.
In parallel, the nightly full scan identifies two residual credentials in legacy test files (commits made before the agent was integrated). Alert to the security team with the file references. The team decides to rotate the exposed credentials and clean the files from the repository.
Declarative patterns and allowlist from the security team.
Rules are declarative. The security team defines in a human-readable format the credential patterns to recognise (API keys for specific services, token formats, connection string formats), alert thresholds, and the incident handling flow. Rules live in the customer's repository, version-controlled, validated at agent startup.
- 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 (7 native patterns: API key, JWT, AWS keys, PEM, connection string), prompt-injection
- Native channels
- Slack, Telegram, OpenAI-compatible HTTP (git pre-commit webhook)
- GitHub, GitLab, Bitbucket integration
- native ghPR/ghIssue tools for GitHub; dedicated adapter during delivery for other systems
- Memory
- persistent per instance
- Registry
- immutable, queryable with a standard SQL client
Frequently asked questions about the agent.
The credential-detector is one of the ten built-in runtime controls; it applies 7 patterns to text leaving a runtime agent. Secret Detection is a dedicated agent that applies the same logic (plus additional declarative patterns) to scanning repositories. The two work at different points: the runtime control protects agent output; Secret Detection protects the project's code.
For the pre-commit hook, yes: the commit is blocked when the agent identifies a credential in plain text. The developer must remove the credential and recommit. The block is structural — it prevents exposed credentials from reaching the remote repository.
False-positive patterns (e.g., test values that look like API keys but are explicitly synthetic) can be marked by the team with specific code comments or allowlist rules in the repository. The agent learns from the customer's repository patterns.
The typical pattern for Secret Detection is 3-6 weeks. Discovery one week, pattern and allowlist rule configuration 1-2 weeks, integration with the customer's repositories 1-2 weeks, hand-off to the security team one week.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Secret Detection would be configured for the customer's case. Repositories, credential patterns, team thresholds.