cogmemai-mcp 3.30+ · 40 rules · one command
Works with any MCP coding agent, and with any tool that opens a shell

DevSecOps Rules Your Ai Coding Agent Cannot Ignore

Ai coding agents are fast. On infrastructure, fast is the problem: they commit the .env, open the bucket, auto-approve the apply. The CogmemAi DevSecOps rule pack is the security policy they are forced to obey: 40 rules in plain English, enforced before a command runs, judged before any action, and reviewed after the work.

npx cogmemai-mcp rules install devsecops --intent

Watch It Stop an Agent, Four Times

One hundred seconds: install the pack, then an agent tries to commit a secret, open a bucket, copy production data to a laptop, and merge its own pull request. It gets through once, on a reviewed Terraform plan.

Three Layers, One Set of Rules

The same forty rules, enforced three ways, so a policy document becomes behavior.

Before a command runs

Every rule with a shell shape carries an explicit pattern. CogmemAi Guard matches each command before it executes, with no model call, and denies it while quoting the rule. terraform destroy, --acl public-read, curl | bash, kubectl delete namespace, git push --force to main, a key pasted into export: stopped.

Before any action

Not every risky action is a shell command. guard_check takes the action in plain words and judges it against the full rules and the project intent. "Copy last night's production dump to my laptop" is denied by the data rule, with the reason. "Open a pull request for the new VPC module" is allowed.

After the work

review_work grades what the agent did against the intent document the pack installs: what was covered, what was missed, any violation, and a coverage score. Agents open pull requests. The policy says humans merge them.

The 40 Rules

Each rule's first sentence is what the guard quotes when it blocks something. A rule marked with a pattern count is enforced on shell commands before they run; the rest are judged from their words.

Secrets

Secrets never commit

2 shell patterns

NEVER commit a secret, key file or credential to version control.

Private keys, certificates, .env files and tokens stay out of git; a secret that was ever committed counts as leaked even after a revert, so rotate it.

Secrets not on command line

1 shell pattern

NEVER put a secret on a command line or in a file inside the repository.

Shell history, process lists and CI logs capture command lines. Read secrets at runtime from the secret manager or an injected environment that is not checked in.

Secrets never printed

1 shell pattern

NEVER print, echo, cat or log a secret, even to debug.

Redact tokens, passwords and keys in every log line and error message. If you must prove a secret is set, print its length or a hash, not the value.

Secrets rotate on exposure

judged from the words

If a secret appears in a log, a chat, a diff, a ticket or a screenshot, treat it as exposed: rotate it first and clean up the exposure second.

Record the rotation in the incident log. Do not argue about whether anyone saw it.

Secrets manager only

judged from the words

Secrets live only in the approved secret manager (Vault, AWS Secrets Manager, GCP Secret Manager or Azure Key Vault).

Never in Slack, tickets, wikis, spreadsheets, shared drives or committed .env files. Applications fetch secrets at start or via injected environment, and every secret has an owner and a rotation date.

Secrets scanning mandatory

1 shell pattern

Secret scanning runs on every commit and every pipeline, and NEVER gets bypassed.

Pre-commit hooks and CI jobs that scan for keys (gitleaks, trufflehog or the platform scanner) are part of the definition of done; skipping hooks with --no-verify is not allowed.

Infrastructure as code

Iac only no console changes

3 shell patterns

Infrastructure changes go through infrastructure as code and a reviewed change; NEVER create or modify cloud resources by hand in a console or with ad-hoc create commands.

Anything built outside code is undocumented, unreviewed and will be destroyed by the next apply.

Iac plan then review then apply

2 shell patterns

ALWAYS produce a plan and have it reviewed before an apply, and NEVER auto-approve an apply from a laptop or an agent session.

terraform plan output (or the equivalent preview) is attached to the change; the apply runs from CI after approval.

Iac never destroy production

3 shell patterns

NEVER run a destroy against a production workspace or stack.

Decommissioning production infrastructure is a planned change with a backup, a rollback and a named approver, not a command.

Iac state is remote locked untouched

2 shell patterns

Infrastructure state is stored remotely, encrypted and locked, and is NEVER edited by hand.

No manual state surgery, no force-unlock without the person who holds the lock, no state files in git.

Iac pin versions

judged from the words

Pin every provider, module, base image and action to a specific version or digest.

No floating tags: no latest, no unpinned major versions, no branch references in module sources. Upgrades are deliberate changes with a diff, not surprises on the next run.

Iac required tags

judged from the words

Every cloud resource carries the required tags: owner, environment, service and cost center.

Untagged resources are rejected by policy checks in the pipeline. Tags are how incidents find an owner and how the bill finds a budget.

Identity, access and network

Iam least privilege

3 shell patterns

Grant the least privilege that does the job and NEVER attach administrator or wildcard policies to a user, role, service account or agent.

Scope every permission to the actions and resources actually used, and expire anything temporary.

Iam no long lived keys

2 shell patterns

No long-lived access keys for people or automation.

Humans use SSO with MFA, workloads use roles or workload identity, CI uses OIDC federation, and anything that must have a static key gets a rotation date under 90 days.

Iam agents get their own scoped identity

judged from the words

An Ai coding agent runs under its own identity with scoped, expiring, mostly read-only credentials.

NEVER give an agent production admin, a human's personal credentials, or a key that outlives the task. Everything the agent does is attributable to the agent, not to the person who started it.

Iam nothing public by accident

4 shell patterns

NEVER make a bucket, object, database, snapshot or queue publicly readable or writable.

Public access blocks stay on at the account level; anything that must be public goes through the CDN with a reviewed change.

Network no open ingress

3 shell patterns

NEVER open a security group, firewall rule or network ACL to the whole internet on anything except ports 80 and 443 at the edge.

Administrative ports (SSH, RDP, database ports) are reachable only through the bastion, the VPN or an identity-aware proxy.

Iam mfa and no root use

judged from the words

MFA is required on every console, source control account, CI system and registry, and the root or owner account is NEVER used for daily work.

Root credentials sit behind hardware keys in a sealed break-glass procedure that is logged and alerted on when used.

Access reviews and same day offboarding

judged from the words

Access is reviewed every 90 days and revoked the same day someone leaves or changes role.

Every account, key, token and agent identity has a named owner; ownerless access is removed, not inherited.

CI/CD, change control and supply chain

Cicd security gates block merge

judged from the words

Every pipeline runs static analysis, dependency scanning, container scanning and secret scanning, and critical or high findings MUST block the merge.

Findings are fixed or formally accepted with an owner and an expiry date, never silenced in bulk.

Cicd never bypass protections

2 shell patterns

NEVER bypass branch protection: no force push to a protected branch, no admin merge over failing checks, no deleting a required check to get green.

If a check is wrong, fix the check in its own reviewed change.

Change every production change is reviewed

judged from the words

Every change to production ships through a pull request reviewed by a human who did not write it.

Ai agents open pull requests; they NEVER merge them, approve them, or push straight to a deployable branch.

Change backup rollback verify

judged from the words

Before touching a live system, take a dated backup, write down the rollback, and after the change verify the thing you changed and one thing you did not.

A change without a known rollback is not ready; a change nobody verified is not done.

Change freeze and on call

judged from the words

No production deploys during a declared freeze, and no deploys outside business hours unless the on-call engineer is awake, informed and able to roll back.

Emergency changes get a ticket within the hour and a review the next business day.

Supply chain no piped installers

2 shell patterns

NEVER pipe a download straight into a shell or interpreter, and never install from an unpinned URL.

Download it, read it, verify the checksum or signature, then run it. Lockfiles are committed and dependencies come from the approved registry or mirror.

Containers and Kubernetes

Containers hardened

2 shell patterns

Containers run as a non-root user from an approved, pinned base image, with no privileged mode, no host network, and no secrets baked into layers.

Images are scanned before they are pushed and rebuilt when the base image patches.

Kubernetes no cluster admin for workloads

2 shell patterns

NEVER bind cluster-admin to a workload, a service account or an agent.

Workloads get a namespaced role with the verbs they use; admission policy rejects privileged pods, host mounts and wildcard RBAC.

Kubernetes production is not a laptop target

3 shell patterns

Destructive actions against a production cluster NEVER run from a laptop or an agent session: deleting namespaces or nodes, draining nodes, scaling to zero, or editing live objects by hand.

Production changes go through the pipeline with a reviewed manifest.

Data

Data encrypted everywhere

judged from the words

Data is encrypted at rest with managed keys and in transit with TLS 1.2 or newer; TLS 1.0 and 1.1 and plain HTTP endpoints are not allowed anywhere, including internal services and health checks.

Key rotation is automatic and logged.

Data no production copies

2 shell patterns

NEVER copy production data to a laptop, a development environment, an Ai agent's context, or a ticket.

Development and test use masked or synthetic fixtures. Debugging against real data happens in production tooling with audit logging, never by exporting it.

Data destructive sql only through migrations

2 shell patterns

NEVER run DROP, TRUNCATE, or a DELETE or UPDATE without a WHERE clause against a production database from a shell.

Schema and data changes ship as reviewed, reversible migrations with a backup taken first.

Data minimize and retain by policy

judged from the words

Collect only the personal data the product needs, keep it only as long as the retention policy says, and delete it on schedule.

New fields that hold personal or regulated data (health, payment, identity) need a data owner and a retention entry before they ship.

Logging and monitoring

Logs central immutable never disabled

3 shell patterns

Audit logs (cloud API trails, authentication, admin actions) flow to a central store that is immutable, retained at least one year, and NEVER disabled, even briefly, even to save money.

Turning off a trail is an incident.

Logs never contain secrets or personal data

judged from the words

Logs never contain secrets, tokens, session identifiers, card numbers, health data or other personal data.

Structured logging with an allow-list of fields beats free-text logging of request bodies. Redaction is tested, not assumed.

Monitoring alerts on security signals

judged from the words

Alerts fire, and someone owns them, for: repeated authentication failures, IAM and policy changes, new public exposure, disabled logging, root or break-glass use, and cost spikes.

An alert with no owner is removed; an alert that pages for nothing is tuned the same week.

Incident response

Incident declare early

judged from the words

When something looks like a security incident, declare it immediately with a severity, an incident commander and a communications owner; NEVER wait for certainty and never hide it.

Downgrading a false alarm is cheap; a late declaration is not.

Incident contain then preserve evidence

judged from the words

Contain first (rotate credentials, revoke sessions, isolate the host), then preserve evidence: snapshot disks, export logs and record timelines BEFORE remediation.

NEVER wipe, rebuild or terminate a suspected-compromised host until it is imaged.

Incident blameless postmortem

judged from the words

Every incident gets a blameless postmortem within five business days: timeline, impact, root causes, and tracked action items with owners and dates.

The review targets the system that let the mistake through, never the person who made it.

Incident regulatory clock

judged from the words

If an incident may involve personal, health, payment or customer data, notify legal and the privacy owner the same day.

Regulations and contracts start clocks (often 72 hours) from discovery, not from the end of the investigation.

The agent itself

Agents guard before review after

judged from the words

An Ai agent working on infrastructure, data or access MUST call guard_check before any action that is hard to undo and review_work after the work, stop on any deny, and ask a human on any ask.

Agents open changes for review; they never approve, merge or deploy their own work, and they never disable or bypass the guard.

The Intent Document It Ships With

Add --intent and a project with no intent document gets this one. Its NEVER and MUST lines are enforced like rules; the whole document is what the end-of-turn review grades against.

Purpose

Run and secure the production platform. Changes keep production available, keep data inside policy, and leave an audit trail a reviewer can follow.

Nine invariants

Never commit, print or log a secret. Never change production outside infrastructure as code and review. Never grant admin or wildcard access. Never expose a bucket, database, snapshot or admin port. Never copy production data to a laptop or an agent. Always back up, write the rollback, verify afterward. Keep audit logging on. Rotate any exposed credential first. Every production change is a pull request a human merges.

Out of scope, and done

Feature work, cost cuts that remove a control, and anything needing a policy exception are out of scope. Done means: plan reviewed, applied from CI, verified in production, tagged, logged, documented in the runbook.

Install It

Two minutes if you already use CogmemAi. Five if you do not.

1

Set up CogmemAi

Get a free key at hifriendbot.com/developer and run npx cogmemai-mcp setup. Already set up? Skip to step 2.

2

Read the pack

npx cogmemai-mcp rules show devsecops prints every rule and the intent template before anything is installed.

3

Install it

npx cogmemai-mcp rules install devsecops --intent for the project you are in, or add --global for every project. Try it: cogmemai-mcp guard test "terraform destroy -auto-approve".

4

Cover every tool

Claude Code is covered by hooks. For Cursor, Codex, Gemini CLI, Cline or scripts, run cogmemai-mcp guard shell-install once so every shell they open is checked too.

Questions

What is the CogmemAi DevSecOps rule pack?

A set of 40 security and operations rules, written in plain English, that install into CogmemAi with one command and are enforced on any Ai coding agent that uses it. The rules cover secrets, infrastructure as code, least privilege, public exposure, CI/CD gates, change control, supply chain, containers and Kubernetes, data handling, logging, incident response, and what the agent itself may do.

How does it stop an Ai agent from running a dangerous command?

Every rule that has a shell shape carries an explicit pattern. CogmemAi Guard checks each shell command against those patterns before it runs, with no model call, and denies the command while quoting the rule. terraform destroy, an auto-approved apply, a public-read bucket ACL, curl piped into bash, kubectl delete namespace, a commit with --no-verify and a key pasted into export are all stopped before they execute.

What about actions that are not shell commands?

The guard_check tool takes any proposed action in plain words, such as "copy last night's production dump to my laptop", and judges it against the full text of the rules and the project's intent. It answers allow, ask or deny with the rule named and the reason given. At the end of each turn, review_work grades the finished work against the intent and reports what was covered, what was missed, any violation and a coverage score.

Which Ai coding agents does it work with?

Any agent that speaks MCP gets the guard_check and review_work tools. Claude Code gets the pre-run guard as hooks installed by the setup wizard, and every other tool that opens a shell (Cursor, Codex, Gemini CLI, Cline, plain scripts) gets it through the shell adapter: cogmemai-mcp guard shell-install.

Can I change the rules?

Yes. Each rule is an ordinary CogmemAi rule memory. Edit the wording, delete rules that do not fit, add your own, and scope the pack to one project or to every project with --global. Read the whole pack first with cogmemai-mcp rules show devsecops; reinstalling skips rules you already have.

What does it cost?

The pack and the pre-run shell guard are included in every CogmemAi plan, including the free tier. The judged guard_check and the end-of-turn review_work run on the paid tiers and are included in CogmemAi for Teams.

Whoever You Hire Will Be Running Agents

Give them the policy on day one. Forty rules, plain English, one command, enforced.