Auth Guard - AI Security Sec-Check Model
Security Sec-Check
by Neurometricāļø Engineering & Product
Auth-Guard is a task-specific model that reviews authentication logic for common flaws (e.g., hardcoded keys).
Auth Guard is designed for Engineering & Product workflows where speed, consistency, and control matter more than generic creativity. Instead of relying on a broad model to guess intent each time, this task-specific SLM is optimized for security sec-check and predictable output quality. That makes it easier to adopt in production pipelines where teams need reliable formatting, lower latency, and reduced hallucination risk.
Engineering teams usually pair issue trackers, pull request metadata, and CI logs from GitHub, GitLab, and Linear. This makes deployment practical for sales ops, customer success, legal, and operations teams that need answers grounded in their own data. Because the model is small and focused, teams can run it with efficient infrastructure while still meeting quality targets for the use case.
Compared with general-purpose models, focused SLMs like this one typically deliver better precision for narrow tasks, lower cost per request, and easier governance. You can start with the free tier, test the model against your business data, and scale usage through Neurometric APIs or ClawPack workflows when performance meets your benchmark.
Model: Qwen/Qwen3-4B-Instruct-2507
This task-specific SLM uses Qwen/Qwen3-4B-Instruct-2507 with a specialized system prompt. The model weights are identical to the base Qwen model ā the task specialization comes from the system prompt and has been validated through our testing pipeline. Need better accuracy? We can fine-tune the model on your data for your specific use case.
Quickstart
Copy-paste code to use Auth-Guard in your project
from openai import OpenAI
client = OpenAI(
base_url="https://api.neurometric.ai/v1",
api_key="YOUR_API_KEY"
)
resp = client.chat.completions.create(
model="neurometric/auth-guard",
messages=[
{"role": "user",
"content": "{\n \"files\": {\n \"auth.js\": \"const crypto = require('crypto');\\n\\n// TEMP: shared secret for HMAC signatures\\nconst SHARED_SECRET = 'abc123';\\n\\nfunction sign(payload) {\\n return crypto.createHm..."}
]
)
print(resp.choices[0].message.content)Test Results
Example Input
Files: Auth.Js: const crypto = require('crypto'); // TEMP: shared secret for HMAC signatures const SHARED_SECRET = 'abc123'; function sign(payload) { return crypto.createHmac('sha256', SHARED_SECRET).update(payload).digest('hex'); } function verify(payload, signature) { // vulnerable: timing-leaky comparison return sign(payload) === signature; } module.exports = { sign, verify }; Routes.Js: const express = require('express'); const { verify } = require('./auth'); const router = express.Router(); router.post('/webhook', (req, res) => { const sig = req.header('X-Signature'); const body = JSON.stringify(req.body); if (!verify(body, sig)) return res.status(401).send('invalid'); res.send('ok'); }); module.exports = router; Context: Webhook authentication uses an HMAC signature header. Need review for common auth flaws. Runtime: Node.js Language: JavaScript
Expected Output
Findings: (1) Hardcoded HMAC shared secret (SHARED_SECRET='abc123') in code; store in config/env and rotate. (2) Signature comparison uses '===' which is not constant-time; use crypto.timingSafeEqual with buffers to avoid timing attacks. (3) Body canonicalization risk: signing JSON.stringify(req.body) may not match sender's exact bytes; verify against raw request body. Recommendation: read raw body, compute HMAC with secret from env/secret manager, compare with timingSafeEqual, and validate header presence/format.
Actual Model Response
You're absolutely right to flag this ā the provided webhook authentication code has several critical security flaws, especially in the context of HMAC-based authentication. Let's go through a detailed review of the common authentication flaws present in your code and how to fix them.
---
š Security Review: Webhook Authentication (HMAC)
šØ 1. Hardcoded Shared Secret (`SHARED_SECRET = 'abc123'`)
Flaw: The secret is hardcoded in the code ('abc123'), which is highly insecure.
Risk: Anyone with access to the source code can easily extract the secret and forge signatures.
Best Practice: Secrets should be:
Stored in environment variables.
Never committed to version control.
Rotated regularly.
ā Fix:
```js
// Instead of hardcoded:
const SHARED_SECRET = 'abc123'; // ā BAD
// Use environment variable:
const SHARED_SECRET = process.env.HMAC_SECRET || 'fallback-secret'; // ā Better
```
> ā ļø Even better: Use a secure secret manager (e.g., AWS Secrets Manager, Hashicorp Vault, or environment variables in production).
---
šØ 2. Timing-Attack Vulnerable `verify()` Function
Flaw: The comparison sign(payload) === signature is timing-leaky.
Risk: An attacker can use timing attacks to infer information about the secret or payload by measuring how long the comparison takes.
Example: If the signature is correct, the comparison completes quickly; if not, it may take longer ā revealing patterns.
ā Fix: Use constant-time string comparison to prevent timing leaks.
```js
function verify(payload, signature) {
const expected = sign(payload);
// Use constant-time comparison
return crypto.timingSafeEqual(Buffer.from(expected, 'hex'), Buffer.from(signature, 'hex'));
}
```
> š crypto.timingSafeEqual() ensures that the comparison takes the same time regardless of whether the values match or not.
---
šØ 3. Missing Input Sanitization / Payload Validation
Flaw: The payload is directly passed to sign() and verify() without validation.
Risk: Malicious payloads (e.g., large, crafted JSON) could cause:
Memory exhaustion.
Denial of service (DoS).
Signature collision or manipulation.
ā Fix: Validate and limit the size of the payload.
```js
function verify(payload, signature) {
// Limit payload size to prevent DoS
if (payload.length > 10000) {
return false;
}
const expected = sign(payload);
return crypto.timingSafeEqual(Buffer.from(expected, 'hex'), Buffer.from(signature, 'hex'));
}
```
> ā ļø Also consider validating the payload structure (e.g., expected fields) to prevent injection.
---
šØ 4. No Header Validation or Sanitization
Flaw: The code assumes req.header('X-Signature') is always present and valid.
Risk: An attacker can send a forged X-Signature header or manipulate it.
ā Fix: Validate the header format and ensure it's not empty or malformed.
```js
router.post('/webhook', (req, res) => {
const sig = req.header('X-Signature');
const body = JSON.stringify(req.body);
if (!sig || typeof sig !== 'string' || sig.trim() === '') {
return res.status(401).send('invalid');
}
if (!verify(body, sig)) {
return res.status(401).send('invalid');
}
res.send('ok');
});
```
---
šØ 5. No Rate Limiting or Throttling
Flaw: No protection against brute-force attacks on the signature verification.
Risk: Attackers can flood the endpoint with invalid signatures to exhaust resources.
ā
Fix: Add rate limiting (e.g., using express-rate-limit).
```js
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100 // limit each IP to 100 requests per windowMs
});
router.post('/webhook', limiter, (req, res) => { ... });
```
---
ā
Final Improved auth.js
```js
const crypto = require('crypto');
// ā Use environment variable (never commit!)
const SH
Test this model
Sign in to run your own test cases against this model.
Capabilities
Related models
Frequently asked questions
Does Auth Guard work with CRM systems?
Yes. Auth Guard is built to work with CRM systems, internal docs, and CSV/JSON pipelines. Most teams connect existing APIs or scheduled exports and map records into prompt-ready JSON.
What data format does this model accept?
You can send plain text or structured JSON. For security sec-check, teams usually pass normalized records with field names, context notes, and output constraints.
Why use a task-specific SLM for security sec-check?
Task-specific SLMs are tuned for one business outcome, so they are often more consistent and cost-efficient than general models for repetitive production workflows.
Try This Model
Send a message to try the model
Use via API
FreeView API settings and get a free key. Sign up when you want more keys or billing access.
Need better performance?
We can fine-tune this model on your data for higher accuracy on your specific use case.