Most cloud-native companies in 2026 share a common reality: the engineering team ships multiple times a week, the cloud footprint spans two or three providers, and the security team is two or three people trying to cover an attack surface that grows faster than headcount ever will.
The instinct is to buy more tools. A CSPM here, a CIEM there, a code scanner somewhere else, a separate JIT vendor, maybe a DAM tool, and a compliance spreadsheet that someone manually assembles before every audit. The result is five to eight disjointed dashboards, no correlation between findings, and a security posture that looks busy but is brittle in reality.
This is not a tooling problem. It is a team-design problem.
The way you structure your DevSecOps team — who owns what, where security sits in the org chart, what skills you hire for versus upskill — determines whether security scales with engineering or falls further behind with every sprint.
This guide is for engineering leaders, platform heads, and security managers at cloud-native companies who are building or restructuring their DevSecOps function. It covers the specific roles you need, the skills matrix for hiring and upskilling, the organizational models that work at different company stages, and the emerging responsibilities that 2026 demands — including securing AI coding agents.
No assumptions. No generic advice. Just the practical structure that lets a small, well-designed team cover code, cloud, identity, and data without drowning in alert noise.
Why DevSecOps Is a Team-Design Problem, Not a Tooling Problem
Before talking about roles and org charts, it is worth understanding why the “hire one security person and give them tools” approach fails.
The surface area problem
A typical mid-market company running multi-cloud (200–2,000 employees, deploying multiple times a week) has the following security surfaces:
- Cloud infrastructure — AWS, Azure, GCP accounts with hundreds of services, IAM roles, networking rules, and storage configurations
- Code and CI/CD pipelines — repositories, build systems, container registries, deployment pipelines, secrets in environment variables
- Identity and access — human users, service accounts, cross-account roles, third-party integrations, and now AI coding agents with cloud credentials
- Data tier — databases, data warehouses, object storage containing customer PII, financial records, and regulated data
- Runtime workloads — VMs, containers, Kubernetes clusters, serverless functions running in production
- Compliance — SOC 2, ISO 27001, HIPAA, PCI DSS, DPDPA, and any industry-specific frameworks that require continuous evidence
One person cannot meaningfully cover all of these. Two people with eight separate tools cannot either — because the tools don’t talk to each other, the alert streams are independent, and no one has time to correlate a misconfiguration in cloud with the IAM role that amplifies it and the code commit that introduced it.
The integration tax
Every additional point tool you buy adds:
- Another dashboard to check
- Another alert stream to triage
- Another vendor relationship to manage
- Another integration to maintain (frequently costing one full-time engineer’s worth of effort)
- Zero correlation with anything else in the stack
The team-design insight is this: the right organizational structure reduces the need for tool sprawl, because clear ownership means each person knows their domain deeply, cross-functional collaboration replaces cross-tool correlation, and platform consolidation becomes a natural priority when the team is structured to think in surfaces rather than in silos.
What “DevSecOps” actually means in 2026
DevSecOps is not a rebranding of the security team. It is an operating model where:
- Security is a shared responsibility distributed across engineering, platform, and a dedicated security function
- Security controls are embedded in developer workflows (CI/CD, IDE, PR reviews) rather than applied after deployment
- Security findings come with remediation context — not just “this is broken” but “here is the copy-paste fix”
- Access governance is automated (Just-In-Time, not just-in-policy)
- Compliance evidence is generated continuously as a byproduct of security operations, not assembled manually before audits
The team structure must support this operating model. Let us build it role by role.
The Core Roles in a DevSecOps Team
The specific roles you need depend on your company’s stage, cloud complexity, and regulatory environment. Below are the six roles that a mature DevSecOps function requires. Smaller teams combine several of these into one person; larger teams specialise further within each.
1. DevSecOps Lead / Head of Cloud Security
What they own: The overall security posture, the relationship between security and engineering leadership, the tooling strategy, the compliance narrative, and the team’s roadmap.
Why this role matters: This is the person who translates security risk into business language for the CTO, VP of Engineering, or CISO. They decide whether the team builds, buys, or consolidates. They own the budget conversation and the board narrative around security posture.
Day-to-day responsibilities:
- Define and maintain the security roadmap aligned with engineering priorities
- Own vendor evaluation, consolidation strategy, and tooling budget
- Report security posture to leadership (CISO, CTO, or board) in terms of risk reduction and compliance readiness
- Coordinate incident response and post-mortem processes
- Set the team’s alert-handling SLAs and escalation paths
- Drive the “consolidate five tools into one platform” conversation when tool sprawl becomes unsustainable
Required skills:
- Cloud architecture fluency across at least two major providers (AWS + Azure, or AWS + GCP)
- Deep understanding of compliance frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS, DPDPA)
- IAM design and identity governance at the organizational level
- Vendor management and procurement (including marketplace-based procurement)
- Communication: the ability to explain blast radius to a non-technical board member and discuss attack paths with a principal engineer in the same day
Typical titles: Head of Cloud Platform, Director of DevSecOps, VP of Security Engineering, Senior Security Manager.
2. Platform Security Engineer
What they own: The security of CI/CD pipelines, infrastructure-as-code, container registries, deployment automation, and the developer-facing security tooling experience.
Why this role matters: This is the person who makes security invisible to developers. They configure the quality gates, set up the automated scanning, and ensure that security feedback appears in the developer’s PR — not in a separate dashboard the developer never checks. If security slows down deployment velocity, this person hears about it first.
Day-to-day responsibilities:
- Configure and maintain security scanning in CI/CD pipelines (SAST, SCA, secrets detection, IaC scanning)
- Manage container image scanning and registry governance (only signed, scanned images deploy to production)
- Implement and tune quality gates — the automated rules that block or warn on security issues before code reaches production
- Own the secrets management infrastructure (vault configuration, rotation policies, emergency access procedures)
- Build and maintain security tooling integrations (Slack notifications, Jira ticket creation, PagerDuty alerts)
- Ensure that security findings surface where developers already work (PR comments, IDE annotations, Slack threads)
Required skills:
- Deep expertise in CI/CD systems (GitHub Actions, GitLab CI, Jenkins, ArgoCD)
- Infrastructure-as-Code (Terraform, Pulumi, Bicep) and Policy-as-Code (OPA, Sentinel)
- Container ecosystems: Docker, Kubernetes, Helm, container registries
- Secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
- Developer workflow empathy — understanding that a security gate that takes 20 minutes will be bypassed
Typical titles: Platform Security Engineer, DevSecOps Engineer, Security Automation Engineer, CI/CD Security Lead.
3. Cloud Security Engineer (Posture & Identity)
What they own: Cloud Security Posture Management (CSPM), Cloud Infrastructure Entitlement Management (CIEM), Kubernetes Security Posture Management (KSPM), and the ongoing detection of misconfigurations and identity risks across all cloud accounts.
Why this role matters: This is the person who sees across your entire cloud estate and knows which misconfigurations are actually dangerous versus which are noise. They understand that a public S3 bucket with no sensitive data is different from a public S3 bucket connected to a role that can reach your production database. They think in attack paths, not individual findings.
Day-to-day responsibilities:
- Monitor and triage cloud posture findings across AWS, Azure, GCP, and OCI
- Investigate identity risks: over-privileged roles, unused service accounts, cross-account trust relationships, toxic permission combinations
- Build and maintain custom detection rules for organisation-specific risk patterns
- Conduct attack-path analysis: tracing how a single misconfiguration chains with other weaknesses to create exploitable paths to sensitive assets
- Own the remediation workflow: ensuring findings get to the right team with the right fix instructions, and tracking closure
- Manage Kubernetes security posture for EKS, AKS, GKE clusters
Required skills:
- Deep AWS, Azure, or GCP IAM knowledge (policy evaluation logic, trust relationships, permission boundaries)
- Attack-path reasoning — the ability to chain findings across identity, network, and workload layers
- Kubernetes RBAC and network policies
- Multi-cloud fluency (at minimum, understanding the equivalent constructs across two providers)
- Query languages for asset graphs (if your platform supports natural-language or structured queries across the asset graph)
- Understanding of compliance control mappings (how a specific finding maps to SOC 2 CC6.1 or PCI DSS Requirement 7)
Typical titles: Cloud Security Engineer, Security Posture Analyst, CIEM Engineer, Cloud Security Architect.
4. Application Security Engineer (Shift-Left)
What they own: Code-level security — SAST, SCA, secrets scanning, and the developer-facing experience of security in the software development lifecycle.
Why this role matters: Finding a vulnerability in production is 100x more expensive to fix than catching it during code review. This person ensures that security feedback reaches the developer at the moment they are writing the code — in the PR, in the IDE, in the commit hook — not three weeks later in a separate security report.
Day-to-day responsibilities:
- Configure and tune SAST (Static Application Security Testing) rules to reduce false positives to a manageable level
- Manage SCA (Software Composition Analysis) — tracking vulnerable dependencies, generating SBOMs, and prioritising based on reachability
- Own secrets scanning across all repositories — blocking commits that contain leaked credentials before they reach the remote
- Conduct security design reviews for new features and architecture changes
- Build developer education programs: secure coding guidelines, common vulnerability patterns, and “lunch and learn” sessions
- Track and report on shift-left metrics: percentage of vulnerabilities caught pre-production, mean time to remediate, developer adoption of security tooling
Required skills:
- Application security fundamentals (OWASP Top 10, CWE, secure coding patterns)
- SAST and SCA tooling (Semgrep, SonarQube, Snyk, or platform-native scanners)
- Understanding of multiple programming languages and their specific vulnerability patterns
- Developer empathy — the ability to write a security finding description that a developer can act on without additional research
- Secrets detection patterns (entropy-based scanning, regex patterns, custom patterns for internal credential formats)
- Git workflows and code review processes
Typical titles: Application Security Engineer, AppSec Lead, Product Security Engineer, Shift-Left Security Engineer.
5. Identity & Access Engineer (JIT / Privilege Management)
What they own: Zero-standing-privilege architecture, Just-In-Time access workflows, non-human identity governance, and the audit trail for all access events.
Why this role matters: Standing privilege — long-lived admin credentials, shared database passwords, service accounts with permanent production access — is the single largest amplifier of blast radius. If a credential is compromised, the damage is proportional to what that credential can reach. This person’s job is to ensure that every identity (human, machine, or agent) has access only when it is needed, only to what is needed, and only for as long as needed.
Day-to-day responsibilities:
- Design and implement JIT access workflows across cloud, database, Kubernetes, VMs, and SaaS
- Manage the approval chain: who can approve what, when policy-based auto-approval is appropriate, and how Slack/Teams-based approval flows work
- Own non-human identity (NHI) governance: service accounts, CI/CD tokens, API keys, cross-service credentials
- Implement and monitor auto-revocation: ensuring that temporary credentials expire and are cleaned up without manual intervention
- Build and maintain the identity-stamped audit trail for every access event (satisfies SOC 2, ISO 27001, PCI DSS access logging requirements)
- Track privilege creep over time: identifying roles and accounts that accumulate permissions beyond their stated need
Required skills:
- Deep IAM expertise across cloud providers (AWS IAM, Azure AD/Entra ID, GCP IAM)
- JIT access architecture: broker patterns, credential vending, auto-revocation, MCP-based access for AI agents
- Workflow automation (Slack API, Teams API, custom approval bots)
- Database access management (connection brokering, dynamic credential generation)
- Audit and compliance: understanding which regulations require what evidence around access governance
- Kubernetes RBAC and namespace-level isolation
Typical titles: Identity Security Engineer, IAM Engineer, Privilege Management Engineer, Access Governance Lead.
6. AI-Agent Security Engineer (Emerging Role — 2026)
What they own: The security of AI coding agents (Claude Code, Cursor, Kiro, Copilot, Codex, Aider) and their interaction with cloud infrastructure, repositories, and sensitive data.
Why this role matters: This is the newest and fastest-growing security surface in 2026. Engineering teams are adopting AI coding agents to accelerate development, and these agents need cloud credentials to function. They call AWS APIs, read infrastructure state, deploy changes, and access repositories. The default pattern — storing long-lived AWS keys in .envrc files for the agent to use — creates permanent, unscoped, unaudited credential exposure. This is the credential incident waiting to happen, and no CNAPP designed before 2024 was built to address it.
Day-to-day responsibilities:
- Define and enforce credential policies for AI coding agents (no hardcoded keys, JIT-only via MCP)
- Implement and manage on-host DLP for coding agents — preventing secret and PII exfiltration before tokens leave the developer’s machine
- Design the MCP (Model Context Protocol) integration architecture for secure agent-to-cloud communication
- Monitor agent activity: what resources are agents accessing, what changes are they making, and are they operating within scoped permissions
- Build guardrails for AI-generated code: ensuring that code produced by agents goes through security scanning before merge
- Collaborate with the Identity & Access Engineer on agent-specific JIT policies (shorter TTL, tighter scope, different approval workflow)
Required skills:
- Understanding of AI coding agent architectures (how Claude Code, Cursor, Copilot, Kiro interact with local environments and cloud services)
- MCP (Model Context Protocol) and agent-to-service authentication patterns
- Data Loss Prevention (DLP) at the endpoint level
- Cloud IAM with specific focus on short-lived credential generation and scoping
- Secure software development lifecycle awareness (to validate agent-generated code)
- Emerging: prompt injection awareness, agent privilege escalation patterns, tool-use auditing
Typical titles: AI Security Engineer, Agent Security Engineer, AI Platform Security Lead. (Note: this title is still crystallising across the industry — you may not find it on job boards yet, but the responsibilities are real and growing.)
The Skills Matrix: What to Hire For vs. What to Upskill
Not every skill needs to be hired from outside. Some of the strongest DevSecOps engineers come from adjacent backgrounds (DevOps, platform engineering, SRE) with targeted upskilling. Here is how to think about it:
Skills you must hire for (hard to develop internally)
These skills require deep domain expertise that takes years to build and are best brought in from experienced hires:
- Cloud IAM security at the architectural level — understanding policy evaluation logic, trust chains, and cross-account attack paths. This is different from “can use IAM” — it is “can reason about how a compromised role chains to reach sensitive data.”
- Attack-path reasoning — the ability to see how individual findings connect into exploitable chains. This is a mindset, not a tool skill.
- Compliance framework expertise — deep knowledge of what SOC 2, ISO 27001, PCI DSS, HIPAA, or DPDPA actually require (not just the high-level intent, but the specific control language auditors evaluate against).
- Application security architecture — secure design patterns, threat modelling, and the ability to review a system design and identify where the vulnerabilities will be before code is written.
Skills you can upskill from DevOps / Platform Engineering
These are adjacent to skills your existing team likely has, and targeted training or certification can bridge the gap:
- IaC scanning and Policy-as-Code — a Terraform expert can learn to write OPA policies. The infrastructure knowledge is the hard part; the security rules are learnable.
- CI/CD security gate configuration — anyone who manages pipelines can learn to add security scanning stages. The workflow skill transfers directly.
- Container image scanning and registry governance — a Kubernetes platform engineer already understands the image lifecycle. Adding security scanning and admission control is an incremental step.
- Secrets rotation and vault management — an SRE who manages infrastructure secrets is already 80% there. The security layer is about policy, rotation cadence, and detection of leaks.
- Monitoring and alerting for security events — if they already build observability, building security-specific alerting uses the same tools and patterns.
Skills you can upskill from Application Security / Software Engineering
- Shift-left tooling integration — a developer who understands the codebase can learn to configure and tune SAST/SCA tools. Their code knowledge makes them better at reducing false positives than a pure security hire.
- Secure code review — senior developers with security training make excellent code reviewers for security-sensitive changes.
- SBOM generation and dependency management — already part of the developer workflow; the security layer is about prioritisation and vulnerability response.
Skills you should invest in now (emerging, high-value in 12–18 months)
These are the skills that will differentiate your team by 2027. Invest now through research time, pilot projects, and conference attendance:
- AI-agent security — MCP integration, agent credential management, on-host DLP, agent behaviour monitoring. This surface barely existed 18 months ago and is now production-critical.
- Database Activity Monitoring — query-level controls, dynamic PII masking, destructive-query prevention. As data privacy regulations tighten globally, this becomes a compliance requirement.
- Non-human identity lifecycle management — as microservices architectures grow and AI agents proliferate, the number of non-human identities can exceed human identities by 10–50x. Managing their lifecycle (creation, rotation, scope, retirement) is an emerging discipline.
- Natural-language security querying — the ability to ask your security platform questions in plain English (“show me all public-facing EC2 instances with access to the production database”) rather than building complex queries. This changes the skill profile needed for junior security analysts.
Organizational Models: Where Does DevSecOps Sit?
There is no single “correct” org chart for DevSecOps. The right structure depends on your company’s size, engineering culture, regulatory requirements, and where decision-making authority lives. Here are three models, when each works best, and the tradeoffs.
Model A: Security Embedded in Platform Engineering
Best for: Startups and mid-market companies (50–500 employees) where security reports into Engineering, the team ships fast, and developer velocity is the top priority.
How it works:
CTO / VP Engineering
└── Head of Platform Engineering
├── Platform Team (infra, CI/CD, observability)
├── Security Engineers (1–3 people, embedded in platform)
└── SRE / ReliabilitySecurity engineers sit inside the platform team. They attend the same standups, use the same task board, and ship security improvements alongside infrastructure improvements. There is no organisational boundary between “platform work” and “security work.”
Strengths:
- Security moves at engineering speed — no handoffs, no separate prioritisation meetings
- Developer empathy is built in: security engineers see the developer workflow daily and design for it
- Fast feedback loops: a security issue found today can be fixed in the same sprint
- Low overhead: no separate team meetings, no separate roadmap, no separate tooling budget fight
Weaknesses:
- Security can lose independence: when velocity is the cultural priority, security findings may be deprioritised as “not a feature”
- Compliance rigour may suffer without dedicated compliance ownership
- Risk of the security function being under-resourced because it competes with platform priorities for headcount
- Audit preparation requires pulling people away from platform work
When to choose this model: When your company has fewer than 500 employees, security does not yet report to a CISO, the CTO or VP of Engineering owns security outcomes, and the team deploys daily or multiple times per week. The embedded model gives you security at speed without the overhead of a separate function.
Model B: Dedicated Security Team with Engineering Liaisons
Best for: Mid-market to enterprise companies (500–5,000 employees) with regulatory requirements, a CISO or VP of Security, and enough scale that a dedicated security function is justified.
How it works:
CISO / VP of Security
└── Director of Cloud Security
├── Cloud Security Engineers (posture, identity, compliance)
├── Application Security Engineers (code, shift-left)
├── Identity & Access Engineers (JIT, privilege management)
└── Security Liaisons embedded in each product/platform teamThe security team is a distinct function with its own budget, roadmap, and reporting line. However, each major engineering team has a designated “security liaison” — a security engineer who attends that team’s planning meetings, understands their roadmap, and provides security guidance specific to their domain.
Strengths:
- Strong independence: security findings cannot be deprioritised by engineering without escalation
- Deep specialisation: engineers focus on their domain (identity, code, posture) rather than being generalists
- Compliance ownership is clear: the security team owns audit readiness and evidence generation
- Career path: security engineers have a clear growth trajectory within a dedicated function
Weaknesses:
- Handoff risk: if liaisons are spread too thin, security feedback arrives too late in the development cycle
- Potential for an adversarial relationship between security and engineering (“the security team is blocking our release”)
- Higher overhead: separate meetings, separate tooling decisions, separate budget conversations
- The liaison model only works if liaisons have enough context in the engineering team to be useful
When to choose this model: When you have regulatory requirements that demand independent security oversight (FSI, Healthcare), when you have a CISO who needs a team, when audit frequency is high (quarterly SOC 2, annual PCI), and when the engineering organisation is large enough that embedded security cannot cover all teams.
Model C: The “Small Team, Big Surface” Hybrid (Platform-Consolidated)
Best for: Companies of any size where the security team is structurally small (3–7 people) relative to the attack surface, and the strategy is to use platform consolidation as a force multiplier.
How it works:
CTO / CISO
└── Head of DevSecOps (1 person)
├── Cloud + Identity Engineer (posture, CIEM, JIT)
├── Code + Pipeline Engineer (AppSec, CI/CD security)
├── Platform + Compliance Engineer (runtime, audit, evidence)
└── Consolidated CNAPP+ Platform (the force multiplier)The team is deliberately lean. Instead of hiring one person per security domain and giving each their own tool, you hire fewer people with broader skills and give them a single consolidated platform that covers CSPM, CIEM, code scanning, JIT, compliance, and runtime detection on one asset graph. The platform does the correlation; the humans do the judgement.
Strengths:
- Cost-efficient: 3–5 people cover what would take 8–12 people with fragmented tooling
- Correlation is automatic: the platform connects a code finding to the cloud asset to the identity to the compliance control — no manual stitching across tools
- Faster onboarding: new team members learn one platform, not eight
- Alert fatigue is structurally reduced: one priority list, not eight independent alert streams
- Compliance evidence is a byproduct, not a project
Weaknesses:
- Platform dependency: if the consolidated platform has a gap, the team feels it immediately
- Requires the team to be more senior (generalists who can context-switch across domains)
- Less deep specialisation in any single area compared to a large dedicated team
When to choose this model: When your headcount is constrained relative to your attack surface (which is most mid-market cloud-native companies), when you are running too many tools and the integration tax is consuming engineering time, and when you want security outcomes rather than security activity.
This is the model that works for companies where the team is small, the surface is huge, and the platform needs to quietly absorb complexity instead of generating more of it.
Making the Team Effective: Operating Principles
Having the right roles and org chart is necessary but not sufficient. The team also needs operating principles that keep them effective as the company grows.
Principle 1: Consolidate, don’t accumulate
Every tool you add is a tax on the team’s attention. Before buying a new point solution, ask: “Can our existing platform do this, or can it be configured to do this?” The goal is fewer tools with better correlation, not more tools with more dashboards.
The practical test: if a misconfig, the IAM role that touches it, the CVE on the workload in front of it, and the CloudTrail event when it was accessed are in five different tools, you do not have a security platform — you have a collection of dashboards.
Principle 2: Remediation is the metric, not detection
It is easy to measure “findings detected.” It is harder — and more meaningful — to measure “findings remediated within SLA.” A team that detects 10,000 issues and remediates 200 is less secure than a team that detects 500 prioritised issues and remediates 480.
Design your team’s processes around remediation:
- Every finding must include copy-paste-ready fix instructions (GenAI-powered remediation playbooks make this possible at scale)
- Findings must route to the team that owns the affected resource, not to a generic security queue
- SLAs should be based on risk (critical: 24 hours, high: 7 days, medium: 30 days) and tracked publicly
Principle 3: Eliminate standing privilege by default
Zero standing privilege is no longer an aspirational goal — cyber insurers and SOC 2 / ISO auditors now ask for it explicitly. Your Identity & Access Engineer should be working toward a state where:
- No human has permanent admin access to production
- No service account has broader permissions than its specific function requires
- No AI coding agent has persistent cloud credentials
- Every privileged session is requested, approved, time-bounded, audited, and auto-revoked
The tools exist to do this today across cloud IAM, database access, Kubernetes, VMs, and even AI agents via MCP. The team-design implication is that someone must own this surface full-time.
Principle 4: Shift left with developer empathy
Shifting left does not mean dumping 500 security alerts into a developer’s PR and expecting gratitude. It means:
- Security feedback appears in the same interface the developer already uses (the PR, the IDE, the Slack thread)
- Findings include context: what is wrong, why it matters, and exactly how to fix it
- False positives are aggressively tuned out — if the team ignores alerts, the alerts are bad, not the team
- Quality gates are calibrated: block on critical and high (secrets, known-exploited CVEs), warn on medium, inform on low
The proof that shift-left works: teams that implement CI/CD quality gates properly catch 90–95% of vulnerabilities before they ever reach production. That is the outcome to aim for.
Principle 5: Compliance is a byproduct, not a project
If your security controls generate their own evidence, compliance is free. If they don’t, compliance is an eight-week fire drill every quarter.
Design the team’s processes so that:
- Every JIT session generates a SOC 2-ready audit trail automatically
- Every posture finding is mapped to relevant frameworks (SOC 2, ISO 27001, PCI DSS, HIPAA, DPDPA) at the moment of detection
- Compliance posture is a real-time dashboard, not a quarterly snapshot
- Audit preparation is an export button, not a project
This means the team’s tooling choice matters: if the platform maps findings to compliance frameworks out of the box, the team avoids hours of manual mapping per audit cycle.
Principle 6: Measure outcomes that matter
The metrics that indicate a healthy DevSecOps team:
- Mean time to remediate (MTTR) — how quickly findings are closed, by severity
- Percentage of vulnerabilities caught pre-production — the shift-left effectiveness metric
- Standing privilege exposure — the percentage of identities with persistent access that could be replaced by JIT
- Tool consolidation ratio — how many security surfaces are covered by how many tools (aim for fewer tools covering more surface)
- Audit preparation time — how many hours/days does it take to assemble evidence for an audit
- Alert-to-action ratio — what percentage of alerts result in a meaningful action vs. being ignored or auto-snoozed
The 2026 Imperative: Securing AI Coding Agents
This section deserves dedicated attention because it represents the fastest-growing security surface in 2026 and the one that most DevSecOps teams have not yet assigned clear ownership.
The new reality
AI coding agents — Claude Code, Cursor, Kiro, Copilot, Codex, Aider, Devin — are no longer experiments. Engineering teams are using them to ship production code. These agents:
- Read your repositories and understand your codebase
- Call cloud APIs to query infrastructure state
- Deploy changes to staging and production environments
- Access secrets managers, databases, and internal services
- Generate and submit pull requests with production-bound code
To do any of this, they need credentials. And the default pattern across the industry right now is dangerous: developers store long-lived AWS access keys, Azure service principal secrets, or GCP service account keys in .envrc files, environment variables, or IDE settings. The AI agent inherits these credentials with:
- No scope limitation (the agent can do everything the key allows)
- No time boundary (the key exists 24/7, whether the agent is active or not)
- No audit trail of what the agent accessed (you know a key was used, but not which agent, which developer, or why)
- No DLP (the agent can potentially exfiltrate secrets or PII to the model provider’s infrastructure)
Why this is a team-design problem
AI-agent security does not fit cleanly into any traditional DevSecOps role:
- It is not purely a cloud security problem (though it involves cloud credentials)
- It is not purely an application security problem (though it involves code)
- It is not purely an identity problem (though it involves credential management)
- It is not purely a data protection problem (though it involves DLP)
It sits at the intersection of all four. Which is why, in most organisations today, nobody owns it. The cloud security team assumes AppSec handles it. AppSec assumes the identity team handles it. The identity team assumes it is a developer-tooling issue. And the developers assume someone in security is thinking about it.
How to assign ownership
For most mid-market teams, the right approach in 2026 is:
Option A (lean team): Add AI-agent security to the Identity & Access Engineer’s portfolio. They already own JIT and credential management — extending JIT to cover agents via MCP is a natural expansion of their domain. Pair this with the Platform Security Engineer owning the on-host DLP configuration.
Option B (growing team): Create a dedicated AI-Agent Security Engineer role (as described in the roles section above). This makes sense when your engineering team has broad agent adoption (50+ developers using coding agents daily) and the credential and DLP surface is large enough to justify a full-time focus.
Option C (mature team): Form a cross-functional “AI Security Working Group” that includes representatives from identity, AppSec, and platform — but with a single DRI (Directly Responsible Individual) who owns the outcomes and the metrics.
The controls that must be in place
Regardless of which ownership model you choose, the following controls need to exist:
-
JIT for agents via MCP — The agent requests access, receives a short-lived scoped credential, uses it for the specific task, and the credential expires automatically. No hardcoded keys.
-
On-host DLP (Coding Agent Firewall) — A control that inspects what the agent is sending to the model provider and blocks secrets, PII, and sensitive data before it leaves the developer’s machine. This is not network-level DLP; it must operate at the IDE/agent level.
-
Agent activity audit trail — Every action the agent takes (API calls, file reads, deployments) logged with the developer’s identity who authorised the session. When the auditor asks “who accessed production at 2 AM,” the answer should be “Agent X, authorised by Developer Y, for task Z, with credentials that expired at 2:15 AM.”
-
Scope limitation — Agent credentials should be scoped to the minimum permissions needed for the specific task. A coding agent writing a feature should not have the same credentials as one deploying infrastructure.
-
Security scanning of agent-generated code — Code produced by AI agents goes through the same SAST, SCA, and secrets scanning as human-written code. No exceptions. The pipeline does not care who wrote the code.
The urgency
Every CISO and platform leader is now asking: “What are our coding agents doing with our cloud credentials?” If your DevSecOps team does not have a clear answer — and a clear owner responsible for providing that answer — this is the gap to close first. The agents are already in production. The security controls need to catch up.
Putting It All Together: A Practical Roadmap
Building a DevSecOps team is not a one-time hiring spree. It is an iterative process that should match your company’s growth and risk profile. Here is a phased approach:
Phase 1: Foundation (team size: 1–2 people)
When: You are a startup or early-stage company with fewer than 200 employees, a small cloud footprint, and no dedicated security function yet.
What to do:
- Hire one DevSecOps Lead / Head of Cloud Security who can be a generalist across posture, code, and identity
- Choose a consolidated platform that covers CSPM, code scanning, and compliance on a single asset graph — this is your force multiplier when headcount is minimal
- Implement the basics: enable cloud audit logging, set up secrets scanning in CI/CD, enable MFA everywhere, start with CIS benchmark compliance
- Embed security in the platform team’s workflow (Model A org structure)
Key outcome: Visibility. You cannot secure what you cannot see. At this stage, the goal is a complete inventory of your cloud assets, a baseline posture score, and automated alerting on critical misconfigurations.
Phase 2: Specialisation (team size: 3–5 people)
When: You are a mid-market company (200–1,000 employees), multi-cloud, deploying daily, and facing your first compliance audits (SOC 2, ISO 27001, or industry-specific).
What to do:
- Add a dedicated Cloud Security Engineer for posture and identity
- Add a Platform Security Engineer for CI/CD and container security
- Implement JIT access for cloud and database (eliminate standing privilege for production)
- Expand compliance coverage: map all findings to relevant frameworks, automate evidence generation
- Shift left: integrate security scanning into every PR, configure quality gates, start developer education
- Begin addressing AI-agent security: implement credential policies, deploy on-host DLP
Key outcome: Remediation velocity. At this stage, the goal shifts from “we can see the problems” to “we close the problems within SLA.” Audit preparation should drop from weeks to hours.
Phase 3: Maturity (team size: 5–8+ people)
When: You are a larger mid-market or enterprise company (1,000+ employees), multi-cloud at scale, under multiple regulatory frameworks, and with broad AI-agent adoption across engineering.
What to do:
- Add specialised roles: Identity & Access Engineer, AI-Agent Security Engineer, dedicated AppSec
- Implement full zero-standing-privilege across all surfaces (cloud, DB, K8s, SaaS, AI agents)
- Build custom detection rules for your organisation’s specific risk patterns (BYOR — Bring Your Own Rules)
- Deploy Database Activity Monitoring with dynamic PII masking and destructive-query prevention
- Establish a security metrics program: track MTTR, shift-left percentage, privilege exposure, and audit prep time
- Consider the dedicated security team model (Model B) or the platform-consolidated hybrid (Model C) depending on your regulatory density
Key outcome: Proactive security. At this stage, the team is not just responding to findings — they are anticipating risks, building guardrails before problems occur, and operating as a strategic function that enables engineering speed rather than constraining it.
Common Mistakes to Avoid
Having worked through the roles, skills, models, and roadmap, here are the patterns that cause DevSecOps teams to underperform:
1. Hiring for tools, not for thinking. The most common mistake is hiring someone who knows how to use Tool X rather than someone who can reason about security architecture. Tools change; the ability to think in attack paths does not.
2. Separating security from the developer workflow. If security findings live in a separate portal that developers need to log into separately, adoption will be low. Meet developers where they are: the PR, the IDE, the Slack channel.
3. Measuring activity instead of outcomes. “We scanned 10,000 resources” is activity. “We reduced critical findings from 200 to 12 in 90 days” is an outcome. Build your team’s performance metrics around the latter.
4. Treating compliance as separate from security. If your compliance program is a separate workstream that runs in parallel to your security program, you are duplicating effort. Every security control should generate compliance evidence as a byproduct.
5. Ignoring the AI-agent surface. The most common blind spot in 2026. If your developers are using coding agents (and they almost certainly are), credentials are being managed in ways your current security controls may not cover. Assign ownership now.
6. Over-specialising too early. A three-person team with one person per domain (code, cloud, identity) creates single points of failure and coverage gaps during PTO or attrition. At small scale, generalists with platform support outperform narrow specialists.
7. Accumulating tools instead of consolidating. Each new point tool adds operational overhead. Before buying tool #6, seriously evaluate whether a consolidated platform could replace tools #1 through #5 with better correlation and less maintenance.
Conclusion: Structure Matters More Than Headcount
The companies that get DevSecOps right in 2026 are not necessarily the ones with the largest security teams. They are the ones where:
- Every security surface has a clear owner
- Security is embedded in developer workflows, not applied after the fact
- The tooling strategy favours consolidation over accumulation
- Standing privilege is eliminated, not just monitored
- AI-agent security is an assigned responsibility, not an open question
- Compliance evidence is generated continuously, not assembled quarterly
A well-structured team of four people on a consolidated platform will outperform a team of twelve drowning in eight separate tools, twelve alert streams, and no correlation between findings.
Start by mapping your current security surfaces to the roles described above. Identify where you have clear ownership and where you have gaps. Then build toward the model that matches your company’s stage — embedded for speed, dedicated for compliance rigour, or hybrid for maximum coverage per headcount.
The surface is large. The team will always be smaller than ideal. The structure and the platform are what close the gap.
The best starting point is visibility. If you do not yet have a complete picture of your cloud posture — misconfigurations, identity risks, code vulnerabilities, and compliance gaps across all your accounts — a one-time security assessment can provide that baseline in under 30 minutes without installing agents or changing your infrastructure.
Request a Free Security Assessment to see where your current gaps are before restructuring your team around them.
People Also Read
- Code Security Best Practices for DevSecOps Teams in 2026
- Transitioning from DevOps to DevSecOps
- Elevate Your Security with IAM Just-in-Time (JIT) Access
- CSPM vs CNAPP: Navigating Cloud Security Evolution
- Top 5 Metrics to Consider for Your Shift-Left Strategy
- Cloud Security for Financial Services: Compliance, JIT Access & Misconfig Playbook
- Shift-Left Security in Practice
- Agentless vs Agent-Based CNAPP: 2026 Buyer’s Guide
