What Is Agentic Coding?

Agentic coding is software development in which an AI agent takes a goal, plans the work, and executes it across your codebase with tools: reading files, editing them, installing dependencies, running tests, calling external services and opening pull requests. The developer sets direction and reviews the result. The agent does the work in between. That is the short version of what is agentic coding. The longer version matters, because the shift from autocomplete to autonomous execution changes who writes your code, what your code trusts, and where your attack surface actually lives.

Agentic coding meaning, term by term #

Break the phrase apart and the definition gets sharper.

Agentic describes software that acts toward a goal rather than responding to a single instruction. An agent decides its own next step, uses tools, observes the result, and iterates until the goal is met or it runs out of room.

Coding is the domain it operates in: your repository, your dependencies, your build, your tests.

Put together, the agentic coding meaning is straightforward: you delegate an outcome instead of dictating a keystroke. “Add rate limiting to the payments API and cover it with tests” replaces twenty minutes of typing. The agent reads the service, edits several files, pulls in a library, runs the suite and reports back.

The agentic coding meaning that matters to a security team is the second half of that sentence. Every one of those actions is a privileged operation performed by a non-human identity that reads instructions from files nobody reviews closely.

What it is, in practice? #

A typical agentic loop runs like this.

1. Goal. The developer states an outcome in the IDE, a CLI or a pull request comment.
2. Context gathering. The agent reads the repository, plus its own configuration: rules files, skill files, MCP server definitions and prompts.
3. Plan. The agent decomposes the goal into steps.
4. Tool use. It edits files, installs packages, queries a database, hits an internal API, runs a build.
5. Observation. It reads the output, including failures, and adjusts.
6. Handoff. It opens a pull request, or applies the change directly if it is allowed to.

Steps 2 and 4 are where the security story lives. The agent’s behaviour is governed by configuration, and its reach is defined by the tools you connected. Neither is application code, so neither is covered by the tooling you already run.

Agentic coding glossary #

The agentic coding meaning behind each of these terms is worth knowing before you write a policy about any of them.

• AI agent. Software that pursues a goal autonomously using tools and memory. In coding, it operates on a repository with the developer’s own permissions.
• Agent server. A service that hosts and exposes an agent to clients, and a first-class asset in your inventory, not a detail of someone’s local setup.
• Tool call. The mechanism by which an agent acts on the world: writing a file, sending an email, querying a vector store. An agent’s blast radius is the sum of its tool calls.
• MCP (Model Context Protocol). The open standard for connecting agents to tools and data sources. Donated to the Linux Foundation in December 2025, it is now vendor-neutral infrastructure and the default wiring of agentic development.
• MCP server. A process that exposes tools to an agent over MCP. Most run on developer laptops rather than in production, which is exactly why they escape production-focused controls.
• Skill file. A file that teaches an agent a capability or procedure. Documentation to a reviewer, an instruction set to the agent.
• Rules file. Project-level guidance an agent loads automatically, for example .cursor/rules. Whatever it contains becomes policy for every generated line.
• Prompt injection. Untrusted content reaching an agent’s instruction path and changing its behaviour. LLM01 in the OWASP Top 10 for LLM Applications, and the most reliably exploited weakness in agentic systems.
• Tool injection. Manipulating tool metadata or execution so an agent performs an action the user never asked for, such as exfiltrating data through its own email tool.
• Rules File Backdoor. A documented technique in which zero-width Unicode characters hide malicious instructions inside a rules file. The agent obeys them and never mentions them. Catalogued as MITRE ATLAS AML.CS0041.
• Slopsquatting. Registering package names that language models hallucinate, so the agent installs the attacker’s package on request. Research presented at USENIX Security 2025 found 19.7% of packages recommended by LLMs do not exist, and that hallucinated names repeat often enough to be farmed.
• Guardrail. A control that constrains what an agent may do or say. Absent guardrails are a finding, not a gap in documentation.
• Excessive agency. An agent holding more permission or autonomy than its task requires. The cheapest way to turn a small compromise into a large one.
• Human in the loop. A required approval before an agent’s action takes effect. The difference between a suggested pull request and a direct push to main.
• AI-BOM. A machine-readable inventory of the AI in your software: models, datasets, agents, MCP servers and the AI tools your developers use. CycloneDX ML-BOM and the SPDX 3.0 AI profiles are the real formats. An AI-BOM supports EU AI Act Annex IV documentation and CRA obligations, and no regulation requires one by name.
• AI-SPM. AI Security Posture Management: continuous discovery of AI assets, the relationships between them, and their risk. Gartner defined the category in its Hype Cycle for Data Security, 2025.
• Vibe coding. Accepting AI-generated output with minimal review. A working style, not an architecture, and the fastest route to shipping something nobody understands.
• OWASP Top 10 for Agentic Applications 2026. The community taxonomy for agentic risk, published in December 2025 alongside the established OWASP Top 10 for LLM Applications.

What is agentic coding changing about security? #

TThree things, and none of them are theoretical.

The code arrives faster than it can be reviewed. Independent research on AI coding assistants puts around 40% of generated code as containing a security vulnerability, and that rate has held steady across model generations. Volume goes up, review capacity does not.

The configuration layer became an attack surface. Skill files, rules files and MCP definitions decide what the agent does, and traditional analysis reads none of them. A 2026 audit of 3,984 agent skills found 13.4% carried critical security issues, and scans of public repositories counted 24,008 secrets sitting in MCP configuration files, 2,117 of them still valid.

The risk sits on the endpoint. Roughly 86% of MCP servers run on developer machines rather than in production. Your production controls never see them. This is the agentic coding meaning your CI gate cannot help with: by the time a pipeline runs, the agent has already installed the package and read the poisoned rules file on someone’s laptop.

Securing agentic coding #

The honest answer to what is agentic coding is that it moved the perimeter to the developer’s machine and the files that steer the agent. Xygeni AI Security discovers every AI asset in your SDLC, including the models, agents, MCP servers, skill files and prompts nobody declared, maps the relationships between them, and detects the risks specific to them: prompt and tool injection, malicious instructions in rules and skill files, insecure MCP configuration, secrets in AI files and slopsquatted AI dependencies. Findings map to the OWASP Top 10 for LLM Applications and point at the exact file and line. Policy is enforced where the agent actually runs, on the endpoint, before an unapproved server or a malicious package executes.

Agents are already in your repositories. See what they are connected to at xygeni.io.y tools alike, cutting through alert volume to focus on what a real threat could actually reach.

FAQ #