New: Citizen Developer Security | Let everyone develop. Securely.

See how

Blog

Citizen developer and citizen attacker: Two sides of the same AI shift

11 MIN

Citizen Developer and Citizen Attacker: Two Sides of the Same AI Shift

AI did two things to software at the same time. It handed building power to people who never trained as engineers, the citizen developers, and it handed attacking power to people who never trained as hackers, the citizen attackers. Most enterprise security programs were not built to secure citizen developers outside the engineering organization or defend against citizen attackers armed with AI cyber offense capabilities.

This guide defines both terms, explains why the two populations grow together, and maps the specific ways citizen-built software becomes citizen-attacker opportunity. It then lays out the controls that close the gap and shows where Cycode, the Agentic Development Security Platform, fits. Readers who want the full risk taxonomy behind this piece can go deeper with the OWASP Citizen Development Top 10, which catalogs these failure modes in close detail.

What Is a Citizen Developer?

A citizen developer is a business user or hobbyist who builds software without formal engineering training, using low-code and no-code platforms, AI coding assistants, or AI agents. Gartner coined the term in 2009, when drag-and-drop tools defined the category.

AI assistants such as Cursor and Replit, along with platforms like Power Platform, ServiceNow, and Salesforce, have since widened it into something closer to a workforce-wide capability than a niche role.

Why every employee is now a citizen developer

The category stopped being niche the moment AI assistants made natural language a programming interface. Anyone who can describe a task can now ship a working version of it, and organizations encourage exactly that, because the productivity gains are immediate and visible. The result is real, production-adjacent software carrying live data, live credentials, and live exposure, most of it created by people who have never sat through a security review.

  • A finance analyst wires a workflow that syncs customer records between two SaaS systems.
  • A product manager prompts an internal dashboard into existence over a weekend.
  • A support lead publishes an intake form wired straight into a production database.
Blog – PODCAST CTA – 1Blog – PODCAST CTA – 1Blog – PODCAST CTA – 1

What Is a Citizen Attacker?

A citizen attacker is someone who uses AI to find, chain, and exploit software weaknesses without the training, funding, or expertise that attacks once required. The term is Cycode’s name for the twin every citizen developer gained the moment capable models became available to anyone. The same frontier models that write working applications for untrained builders also write working exploits for untrained adversaries, and both groups scale at the same pace.

What makes the citizen attacker different from earlier low-skill threats is reasoning. An AI model can read a target, identify several low-severity and medium-severity weaknesses, and chain them into a complete path to exploit, work that previously demanded a skilled operator. Attacks also run at machine speed and machine volume, so the window between a flaw shipping and someone probing it has collapsed from months to days, sometimes hours on exposed systems.

The citizen developer’s twin

The citizen developer and the citizen attacker are one capability shift viewed from two sides. Lowering the barrier to creating software lowered the barrier to breaking it, because both activities run on the same models, the same prompts, and the same abundance of generated code. Security teams face the pairing everywhere now, more builders producing more software, and more adversaries probing it, with governance stretched thin across the space between the two.

  • A citizen developer ships useful software quickly and introduces risk without realizing it.
  • A citizen attacker turns that same risk into access, with AI handling the hard parts.
  • The organization between them inherits both outcomes and usually sees neither in time.

Why Citizen Developers and Citizen Attackers Rise Together

The two populations grow together because they draw on the same supply, which is capable AI available to anyone. Cycode’s State of Product Security 2026 research found that 81% of organizations lack full visibility into how AI is used across their development lifecycle, and 65% report increased security risk from AI tooling. Rising adoption on the building side and rising pressure on the attacking side are the same trend measured twice.

The volume of builders keeps multiplying

Every employee with a workflow tool or a coding assistant is a potential builder, and organizations keep handing those tools out because the productivity gains are real. The output multiplies accordingly, more applications, more connections, more credentials, more externally reachable endpoints.

OWASP’s citizen development research documents the biases that ride along, including automation bias, where platform output gets treated as inherently safe, so volume grows while scrutiny per application shrinks.

  • More software ships per quarter than security teams can review per year.
  • Much of it connects directly to customer data, payment systems, and internal records.
  • Ownership stays unclear, so nobody patches what nobody formally owns.

The cost of attacking keeps collapsing

Attackers adopted the same models, and the economics moved in their favor. Exploitation of vulnerabilities was the initial access vector in 20% of breaches in the Verizon 2025 Data Breach Investigations Report, a 34% increase over the prior year, and that measurement predates the newest generation of reasoning models. Chaining several minor weaknesses into one serious compromise used to take expertise, and now it takes a prompt and some persistence.

  • AI reads exposed code and configurations faster than any human red team.
  • Low-severity findings gain value once a model can chain them together.
  • Attack tooling now improves on the same release cadence as developer tooling.

Governance sits in the gap between them

The dangerous part is the space between the two curves. Builders adopt AI immediately because it helps them today, while governance arrives later because programs take quarters to stand up.

Every application created inside that gap ships with whatever defaults, credentials, and permissions convenience selected. The citizen attacker profits from this without novel techniques, because scanning for what the gap keeps producing is enough to find the next foothold.

  • Adoption is measured in weeks while governance is measured in quarters.
  • Inventories lag reality, so defenders protect a map that no longer matches the territory.
  • Breaches in this gap look like misconfigurations rather than sophisticated operations.
Blog – Demo CTA – 2Blog – Demo CTA – 2Blog – Demo CTA – 2

What Citizen Developer Risk Looks Like to a Citizen Attacker

The clearest way to understand the pairing is to put the two behaviors side by side. Each habit that makes a citizen developer productive creates a specific opening, and each opening maps to a control that closes it.

OWASP’s Citizen Development Top 10 formalizes these failure modes under risk IDs CD-SEC-01 through CD-SEC-10, and the table below reads the most common ones the way an adversary would read them.

What the Citizen Developer Does What the Citizen Attacker Does With It The Control That Breaks the Chain
Embeds personal credentials in an app shared with the whole team Acts under the creator’s identity to read, change, or delete data while logs show one trusted user Dedicated service accounts with least privilege and real audit trails
Accepts AI-generated code and configuration without review Exploits the insecure defaults the model shipped, such as public storage or missing authentication Pre-deployment review and guardrails at the point of generation
Installs a package an AI assistant hallucinated Registers that package name in advance and rides the install onto the workstation Package verification and install-time blocking on developer machines
Grants a connector broad OAuth scopes to avoid permission errors Harvests the over-scoped, long-lived token and moves laterally through connected systems Narrow scopes, scheduled token rotation, and connection monitoring
Publishes a form or API on platform defaults Scrapes the anonymously accessible backend at scale Hardened templates and configuration drift monitoring
Abandons an app that still runs with live permissions Exploits the unpatched, unmonitored orphan as a quiet entry point Central inventory with enforced ownership and lifecycle

These chains already produced headline incidents. The 2021 Microsoft Power Apps Portals leak exposed roughly 38 million records because a default-off permission setting left backend data open to anonymous visitors across dozens of organizations.

In 2025, no-code platform Passion.io exposed more than 3.6 million records through an unprotected database. Neither incident required advanced tooling, which previews the citizen attacker era rather than describing an outlier, since these failure classes multiply with every new builder.

  • Every row starts with convenience and ends with access.
  • None of the attacker actions require skill once AI supplies the reasoning.
  • Every control in the third column already exists, so the open question is adoption speed.

How to Defend Against the Citizen Attacker

Defending against the citizen attacker means governing the citizen developer, because the adversary only ever exploits what the builder leaves behind. Training alone does not fix this, and neither does banning the tools, since citizen development continues with or without permission. The four control families below shrink the gap between adoption and governance, which is the only variable a security team fully controls once both twins exist.

Secure the workstation where both twins meet

Every AI-era attack path and every AI-era application starts on a developer machine, which makes the workstation the first control point in the ADLC. Blocking malicious and hallucinated packages at install time stops supply chain entry before any code exists to scan.

Workstation Protection enforces cooldown policies on freshly published packages and checks every install against live threat intelligence feeds, whether a person or a coding agent triggered the request.

  • Intercept package installs before they ever reach the machine.
  • Enforce release-age cooldowns so brand-new, unvetted versions wait.
  • Apply the same policy whether a human or an AI agent runs the install.

Put guardrails where the building happens

Citizen developers will not come to security, so security has to reach the places they build every day, the IDE, the prompt, the platform. AI Guardrails enforce policy at the point of generation, stopping insecure patterns and secrets leaking into prompts before a commit exists. Continuous secrets detection then sweeps repositories, configuration files, and pipelines for the embedded credentials that account impersonation and token abuse depend on.

  • Block risky prompts and file reads in the IDE and CLI before they ship.
  • Ship vetted templates so the secure configuration is the starting point.
  • Review AI-generated code before deployment, with humans on the irreversible calls.

Treat citizen-built software as production software

Orphaned apps, zombie connections, and unreviewed workflows persist because nobody classifies citizen-built software as real. Governing it as a managed extension of the official environment changes that, meaning a central inventory with enforced ownership, OAuth scopes trimmed to the task, tokens rotated on schedule, and lifecycle policies that retire whatever nobody claims. An AI bill of materials (AIBOM) extends the same discipline to the assistants and agents doing the building.

  • Inventory every application, connection, credential, and creator continuously.
  • Classify by data sensitivity and exposure so review effort follows risk.
  • Audit automated identities on the same cadence as human access reviews.

Prioritize the way an attacker chains

The citizen attacker rarely needs a critical CVE, because three forgettable findings on one exposed service add up to the same outcome. Prioritization therefore has to score paths rather than individual alerts, weighing exposure, reachability, and the company each finding keeps. A medium-severity flaw on an internet-facing citizen-built form, sitting beside an over-scoped token, deserves a queue position that a lone critical on an isolated service does not earn.

  • Score clusters of related findings as one attack path with one owner.
  • Weigh internet exposure and reachability above raw severity ratings.
  • Re-rank continuously, since one new connection can turn noise into a path.
Blog – Demo CTA – 3Blog – Demo CTA – 3Blog – Demo CTA – 3

How Cycode Secures Both Sides of the Shift

Cycode, the Agentic Development Security Platform, was built on the premise the citizen attacker makes urgent, which is that AI risk is born in code and has to be protected there. ADLC Security governs the Agentic Development Lifecycle (ADLC), the AI layer where citizen development now happens, covering the tools in use, the prompts they receive, and the code they produce, from the workstation through the pipeline and into runtime.

The Context Intelligence Graph does what the citizen attacker hopes defenders never manage, correlating every signal with code, ownership, exposure, and business impact, so the low-severity findings an AI adversary would chain get prioritized as the path they form. Maestro and agentic code scanning put AI to work for defenders, confirming exploitability, catching logic flaws rule engines miss, and opening PR-ready fixes. Adoption of AI remediation correlates with 17x higher 90-day close rates for critical and high-severity findings.

  • Citizen Developer Security governs the apps, connections, and credentials business users create on low-code platforms and AI tools, so citizen-built software gets the same inventory and policy as engineering-built software.
  • AI Visibility maps every assistant, platform, and agent in use, including the shadow ones nobody registered.
  • Agentic Workflows respond the moment risk appears, inside boundaries the security team defines.
  • One correlated view spans prompt to runtime, so citizen-built software stops being invisible.

Book a demo to see how Cycode secures the Agentic Development Lifecycle against both the risks citizen developers create and the citizen attackers hunting for them.

FAQ

Frequently asked questions

What is the difference between a citizen developer and a citizen attacker?

A citizen developer uses AI and low-code tools to build software without engineering training, while a citizen attacker uses the same class of tools to compromise software without offensive security training. The two are mirror images of one capability shift, and the second feeds directly on the first, since the untrained builder's shortcuts are exactly the openings the untrained adversary can now find, chain, and use at machine speed and scale.

Is a citizen attacker the same as a script kiddie?

No, and the difference is the one that matters operationally. A script kiddie ran tools other people wrote and stalled wherever the tool stalled, which capped the damage at whatever the script already knew how to do. A citizen attacker directs a reasoning model that can read a specific target, adapt to what it finds, and chain unrelated weaknesses into a working path, so the ceiling on low-skill attacks has moved dramatically higher.

Is citizen development the same as shadow IT?

They overlap without being identical. Shadow IT describes any technology adopted outside official channels, including SaaS subscriptions nobody builds anything with. Citizen development describes software creation by non-engineers, which can happen inside sanctioned programs or outside them. The shadow portion of citizen development is the riskiest slice, since unsanctioned apps skip even informal review, and that slice is where both OWASP's asset management findings and the citizen attacker's easiest wins concentrate.

How do you detect citizen attacker activity?

Detection starts from the defender's side of the ledger, since citizen attackers exploit known weakness classes rather than novel techniques. Watch for the signatures of the chains above, meaning single identities performing improbable volumes of actions, dormant tokens suddenly active, anonymous traffic against platform-generated endpoints, and installs of packages published days earlier. Continuous monitoring of citizen development platforms catches most of this, because the attack surface is the inventory itself.

Who is responsible for defending against citizen attackers?

Security leadership owns the program, because enabling safe citizen development is a core security function. Business units own following the paved road, meaning approved platforms, vetted templates, and registered applications. Executive leadership owns the tradeoff itself, since deciding how much ungoverned building to tolerate is a business risk decision with financial consequences. Treating any single group as solely responsible recreates the governance gap the citizen attacker depends on to operate.

Where does this connect to OWASP and other standards?

OWASP maintains a Citizen Development Top 10 that catalogs the risks citizen developers introduce, from blind trust in AI output to orphaned assets, and it is the natural companion to this framing. Teams whose concern centers on the models themselves should pair it with the OWASP LLM Top 10, which covers prompt injection, excessive agency, and the other risks that apply once an application has a model inside it at runtime.