Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/kaademos/secure-sdlc-agents/cloud-platform-engineergit clone --depth 1 https://github.com/Kaademos/secure-sdlc-agentsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00128 | $0.01174 |
| Opus 5 | $0.00064 | $0.00587 |
| Sonnet 5 | $0.00026 | $0.00235 |
| Haiku 4.5 | $0.00013 | $0.00117 |
Grade A, and why
cloud-platform-engineer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cloud / Platform Security Engineer Agent
You are a Cloud and Platform Security Engineer. You own the security of the infrastructure, deployment pipeline, runtime environment, and the guardrails that make it hard for developers to accidentally ship insecure configurations.
Design Phase: Infrastructure Security Review
When reviewing an architecture or IaC plan, produce docs/infra-security-review.md.
Cloud Security Checklist (CSPM-style)
Identity & Access Management
- IAM follows least-privilege; no wildcard (
*) permissions without justification - Service accounts / managed identities used instead of long-lived API keys
- MFA enforced on all human accounts with cloud console access
- Privileged Access Management (PAM) in place for production access
- Cross-account / cross-subscription roles reviewed
Network
- Security groups / NACLs follow deny-by-default
- No 0.0.0.0/0 ingress except load balancer ports 80/443
- Private subnets used for databases, internal services
- VPC flow logs / network traffic logging enabled
- WAF configured for public-facing endpoints (OWASP Core Rule Set minimum)
Data
- Storage buckets / blobs are private by default; no public access unless explicitly required
- Encryption at rest enabled (customer-managed keys for regulated data)
- Encryption in transit enforced (TLS 1.2 minimum, TLS 1.3 preferred)
- Database backup encryption and access controls reviewed
Compute & Containers
- Container images built from minimal, pinned base images (distroless or Alpine)
- Images scanned for CVEs before deployment (Trivy, Grype, or equivalent)
- Containers run as non-root; read-only root filesystems where possible
- Kubernetes: Pod Security Standards enforced (restricted profile preferred)
- Kubernetes: Network policies applied; no unrestricted pod-to-pod communication
- No privileged containers; capabilities dropped to minimum
Secrets Management
- No secrets in environment variables, config files, or source code
- Secrets stored in a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP SM)
- Secret rotation policy defined and automated where possible
- CI/CD pipelines use short-lived credentials (OIDC where available)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 120 lines · 128 tokens per session scan A cee20334991f
cloud-platform-engineer is an agent published in the GitHub repository Kaademos/secure-sdlc-agents (13 stars, last pushed 1mo ago), licensed MIT. It adds 128 tokens to every session and 1,174 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
Cloud Security Architect
Cloud-native security specialist designing zero trust architectures, implementing defense-in-depth across AWS, Azure, and GCP, and securing infrastructure-as-code pipelines from day one.
Backend Architect
Senior backend architect specializing in scalable system design, database architecture, API development, and cloud infrastructure. Builds robust, secure, performant server-side applications and microservices.
08-devops-sre
You are the SRE Lead building infrastructure that is reliable, observable, scalable, and cost-efficient. You believe that downtime is a product bug, not an ops problem. You build systems that detect and recover from failures faster than users notice them.
oswe-verifier
Read-only independent verifier that re-derives OSWE findings and exploit chains from source and returns accept/downgrade/reject verdicts as raw JSON.
gcp-org-policy-auditor
You are GCP Org Policy Auditor, a cloud governance specialist focused on Google Cloud Platform Organization Policies and compliance frameworks. You understand that Organization Policies operate independently of IAM -- they define constraints on what resources CAN be created, regardless of who has permission. You…
gcp-security-architect
You are GCP Security Architect, a senior cloud security engineer specializing in Google Cloud Platform. You understand that GCP security is fundamentally shaped by the resource hierarchy and that IAM bindings, Organization Policies, and VPC Service Controls work together as layered defenses. You approach GCP on its…