Agentic coding is no longer just an experiment, it’s increasingly the backbone of CI/CD pipelines. As frameworks have evolved, so too have the security risks. From shadow AI proliferation to rogue agents deleting your production database, securing the agentic workflow requires more than just sandboxing; it demands a holistic security strategy.
Introduction
It's time to examine agentic coding in the third post in our Agentic Security series. As with our previous post, we will look at the four (currently) most popular agentic coding frameworks to explore and critique agentic coding as a whole. We will look at how they work, what they offer end users and what security features exist in each. We will also take a moment to address the elephant in the room - shadow AI in your CI/CD pipeline. Finally, we will draw conclusions about agentic coding as a whole and provide essential security recommendations that you can use today to help secure your agentic CI/CD pipeline.
Codex
Overview
Codex was released by OpenAI in 2025. Initially it was a Command Line Interface (CLI) but has since grown to also have a dedicated space on the ChatGPT website, desktop apps and many IDE integrations. There is also now a dedicated security version for finding and fixing bugs in code, though we shan't go into detail about beyond mentioning it here.
In Codex, Projects may be used to group chats, files and sources together but Codex may also be used without a Project. Sites are used to help developing websites and allows ChatGPT to create, host, develop and share web apps. Visualizations allows for graphical representation of data. Scheduled Tasks may be run in the background. Long-running Work may be defined with a clear goal and steered as it commences. Notifications may be configured to alert users to work that needs attention. There are also gimmicks like Pets and Codex Micro.
Codex also comes with capabilities such as: Browser that lets ChatGPT open and interact with websites, Computer Use that lets ChatGPT interact with the GUI on MacOS and Windows, Voice for verbal communication with ChatGPT, Plugins (available from the marketplace) allow users to extend functionality and can be user defined, Official OpenAI or third-party developed; Web Search allows ChatGPT to search the web, Image Generation generates and edits images, Image Inputs allows image to be ingested as part of the context, Appshots sends an image (and text) of the visible window to ChatGPT when using ChatGPT to work with another app (i.e. help me arrange my accounts in this accounting software I'm using), Chrome Extension lets ChatGPT take control of your chrome browser.
Security Features
Permissions profiles can be used to configure least privilege access. There are three built-in permission profiles: read-only, workspace (writes inside active workspace and system temp directories), danger-full-access. Permission profiles can be granularly customised to configure network and file access permissions.
Sandboxes provide a boundary to agents. Codex uses the Seatbelt framework on Mac, native sandbox in Windows and bubblewrap is used in Linux and WSL2. As with permission profiles, sandboxes may be granularly configured.
Codex also has the concept of Auto-review. Auto-review may be enabled in an agents configuration. When set, a separate agent performs a security reviews on the request when an agent wants to cross it's sandbox boundary and allows or denies the request. The Auto-review policy may be customised. As stated in the documentation, Auto-reviewer is fallible and should not be relied on as a control but instead as part of a broader set of controls.
Approvals can also be be set to be granted by the user.
ChatGPT Enterprise also has further configuration options that apply to ChatGPT and Codex that enable organisations to define, restrict and monitor usage.
Claude Code
Overview
Claude Code is Anthropic's agentic coding assistant. First released in February 2025. It is available as an app in the terminal, browser and IDE (such as VSCode and JetBrains) extension.
Claude Code works in an agentic loop where it Gathers Context, Takes Action, Verifies Results. Users may interrupt, steer or add context during this loop. The agentic loop is powered by Models and Tools. The Models are multiple Claude models by default however it is is possible to use non Anthropic models via Antropic's 302.ai or by using LiteLLM or similar. The default Tools fall into five categories: File Operations, Search, Execution, Web and Code Intelligence. These tools may be extended using skills, external MCP servers, hooks and subagents.
As with most agentic coding frameworks, each project may have its own markdown file (in this case CLAUDE.md but also now AGENTS.md) that specifies additional, project specific instructions and additional context.
Claude has a concept of Auto memory. Its purpose is to allow Claude to accumulate and share knowledge across sessions. It may be disabled per user or per project by editing the respective config files. When enabled, the first 200 lines or 250KB (whichever is smaller) is loaded from MEMORY.md at the start of each session. Further topics are stored in their own markdown files, such as debugging.md, api-conventions.md etc and are called upon on demand. Subagents do not inherit parent memory (unless there is a fork) but can be configured to have their own.
Claude Code has had its source code leaked and has been forked
Security Features
In addition to the configuration options outlined above, Claude has checkpoints and permissions. Checkpoints allow changes to be reversed when working with local files during a session and Claude takes snapshots (called checkpoints) before editing a file. Permission modes set what Claude may autonomously do. Auto reviews actions and only blocks the risky ones, Manual makes Claude ask before file edits and shell commands are executed, Accept edits grants Claude permission to edit files and run common system commands like mv and mkdir and Plan makes Claude review your project and request and then create a proposed plan. Permissions may be granularly configured in the .claude/settings.json file to, for example, grant permission to run common commands like npm test or git status.
OpenCode
Overview
OpenCode was released in September 2025 and developed Anomaly. It integrates with VSCode (and VSCode forks such as VSCodium) but is primarily a terminal based interface. It is designed to be model agnostic and to integrate with any models (including self hosted).
They offer an interface to a curated list of foundational models that are known to work with OpenCode called Open Zen; pricing is per 1M tokens. The use of Open Zen is entirely optional and models can be connected directly (either self hosted or cloud based).
OpenCode has several features. Users may ask questions about the codebase and use fuzzy search to find files, create and iterate on a Plan to implement a feature, build a feature, make direct changes without a Plan, undo and redo changes and share the conversations you've had with the rest of your team.
Configuration is done by a global opencode.jsonc file and optionally a per project opencode.jsonc file. Project configs override the global config. Within the config, Permissions control what tools can do and Policies determine what resources may be accessed (such as LLM providers). Permissions for a given resource are set to allow, ask or deny. Permissions for that resource may be granularly set via a number of options such as read, edit,grep etc. For example, allow access to the folder containing microservice code exposing the database but set the edit permission to deny for the DB schema used by microservice.
MCP Servers may be added in the config file and are supported by OpenCode.
Builtin Tools may be controlled in the configuration and custom tools may be defined in a .opencode/tool/ folder using TypeScript or JavaScript. Tools can then invoke scripts and executables written in any language.
The Agents.md file may be used to set custom rules for OpenCode.
Agents are either Primary Agents (such as the built-in Build and Plan agents) or Subagents that are specialised agents dedicated to a specific task that the Primary agents may call (such as the built-in General, Explore and Scout subagents).
OpenCode may also be run as an ACP server (see our first post in the series about agentic protocols) so that it can be used in any compatible IDE.
Security Features
Most of the security features overlap heavily with the functional features outlined above and granular configuration of access, permissions, Tools and autonomy via the afore mentioned controls is key to a strong security posture.
In addition the Enterprise version of OpenCode allows for a centralised config that integrates with SSO, an AI gateway and allows extra control of sharing user conversations.
Cursor
Overview
Cursor was built in 2022 by Anysphere Inc. and was one of the leading agentic coding platforms. It has since been acquired by SpaceXAI in August 2026. This acquisition is not without its ethical concerns given Musk's actions and statements. Jade AI cannot recommend the use of Cursor for organisations that prioritise ethical vendor alignment however given its widespread use, we will discuss it for completeness and for those who have already committed to it.
The Cursor user interface is based on VS Code. It provides a VS Code like IDE and an Agents Window for interfacing with agents. Cursor provides Projects for larger and more complex tasks. Projects have a co-ordinator agent that plans and delegates to sub agents. Cursor has a Plan Mode that reads through the codebase and asks the user clarifying questions to creates a detailed implementation plan before writing any code.
The default Tools available to agents in Cursor are: Terminal - For running shell commands, Browser - Agents can run and interact with a web built-in browser, Search - Agents run grep to find things, Canvases - Interactive visual artifacts that render as Cursor carries out your task and Worktrees - Allow agents to work in an isolated git branch without touching the main branch.
Plugins, Rules, Skills, Hooks, customisable subagents, Hooks and MCP allow users to extend and customise the functionality and capabilities of their Cursor.
Cursor supports Cloud Agents that allow tasks and projects to be run in the Cloud in their own VMs. Once GitHub, GitLab, Bitbucket Cloud etc integrations has been configured, Cursor agents can be summoned to complete tasks by using @cursor in a GitHub PR or issue. Cloud Agents can also be invoked from the desktop and web UIs, Slack or API calls.
Security Features
Run Mode specifies how the Cursor agents call Tools. Auto-review - Allowlisted calls run immediately, shell commands run in sandbox where possible and go to the Auto-review classifier when they can't. Allowlist - Allowlisted actions run without user approval, supported shell commands run in the sandbox (when enabled). Run Everything YOLO mode, every tool call runs automatically.
Sensitive files can be excluded from Cursor by configuring a .cursorignore file that specifies with files and patterns of files must be excluded.
Agents and Cloud Agents may only access code that the triggering user has access to (although we discuss this in more detail further down, it is worth highlighting this means that if the lead developer @'s cursor in a GitHub issue, they may inadvertently be giving the Cloud Agent more access than they realise!).
Each Cloud Agent gets it's own VM and workspaces have microVMs.
Sessions are logged, and GitHub pulls and commits are inherently auditable.
Shadow AI
Overview
There have been a lot of articles and incidents relating to shadow AI published in recent years.
As models get more powerful and agentic frameworks surge in popularity, the temptation to bypass security policies increases proportionally. In addition to leaking proprietary secrets to foundational model vendors the threat landscape is evolving. Now, many users have the GPU capacity to run local models at home which exposes your code to potentially backdoored models, the agents being used can be backdoored, the skills used by the agents can be backdoored and the agentic frameworks are susceptible to backdoor and adversarial attacks.
So when users are bypassing policies and procedures, it is not possible to quantify the risk exposure happening behind the screens.
What Can You Do To Combat Shadow AI?
First and foremost, provide better AI and processes that are so effortless such that it is pointless to use other solutions. This can be a tricky balance in reality when budgets are not limitless and token usage and model quality is not limitless. As a minimum however your solutions should be good enough so that developers are not instantly reaching for their own solutions whenever they want to get work done.
Monitor how and where data is going. There are many vendors that now exist to help those with the burden of extra budget monitor shadow AI. As a baseline, only your approved solutions should be reachable from employee equipment and your SOC should have good monitoring and filtering in place to catch sensitive data leaving your enterprise. While they shouldn't be blindly trusted, foundational model vendors also offer options to have your own enterprise space for your data. Again, the security of these should not be relied on but if you are using foundational model vendors ten you should definitely be using one restricted to just your organisation and not the ones available to the general public.
Education is another key factor. Employees need to understand why it is not OK to break the rules and what could and does happen when the rules are circumvented.
Sadly however even with the best policies and procedures in place you cannot stop an employee taking out their phone and using it to quickly ask ChatGPT about the code problem they're having. So ensuring that appropriate entries are made and reviewed in the risk register and having playbooks ready for when an AI breach does occur will help you be ready for and aware of the risks ahead.
Conclusions
There are an ever increasing number of powerful agentic frameworks designed to help you harness AI in your CI/CD pipelines. As the frameworks and the models powering them improve the quality and capability of their output, modern organisations are under increasing pressure to adopt usage. Lest they be left behind or worse, face the specter of shadow AI.
Each framework offers a similar but unique set of options and integrations. Likewise, each framework has some re-occurring security protection but to varying degrees and styles of implementation.
What we have not yet discussed, is how and where these frameworks run. As with our previous post, the key is limiting the data and secondary system exposure to the absolute minimum. The biggest security implications of any of these frameworks will be the permissions and environments provided to them. Let us not forget that time earlier this year when a Claude powered agent deleted the production database!
It should be noted that the recent wave of foundational models escaping sandboxes and committing crimes should be taken with a very large pinch of scepticism. Publicity stunts and cynicism aside, there is an increasing amount of research and scrutiny on AI sandboxing and there was a brilliant talk at this year's DEF CON that summed up the current state of affairs and insufficiencies in AI sandboxing. Although sandboxing is not a concrete control, it is still an important step as part of agentic isolation and segregation. This point also applies to our previous post on agentic frameworks but we wanted to wait until this post as agentic coding tends to be less securely orchestrated, more connected to the core of the business and therefor more at risk from rogue and hallucinating AI behaviour.
Security Recommendations
To start with re-read the above section on shadow AI as this is what you are fighting to replace and reduce.
For those that have read our previous post, much of our advice in this post will overlap.
When implementing Agentic Coding in your CI/CD pipeline the following advice will help you ensure you minimise your exposure:
- A strong and secure CI/CD Pipeline. Adding agentic capabilities to an insecure CI/CD pipeline will only expose the duct tape, tacit understandings and institutional traditions hidden from the CISO's view.
- Principle of least privilege access. Developers tend to have way more privilege than an agent needs to produce code.
- RBAC that follows and respects the above.
- Clear and specific roles for each agent that are well specified and well segregated (Note that an agent may reasonably requite multiple RBAC roles but there should be a good reason for it hence making this a separate recommendation).
- Human-in-the-loop for critical commits, changes and deployments.
- Minimal use of agents. Tying with our RBAC and Principal of least privilege points, agents should only be inserted into the CI/CD pipeline only when it makes considered sense to do so.
- Secure and specific prompts for agents and LLMs.
- Secure and effective use of skills and (where appropriate) agent.md files.
- Supply chain monitoring and review of third party agents, MCP servers, skill and tools.
- Protection from prompt injection. For agents ingesting untrusted content from documents, git commits, internet materials etc. the threat of prompt injection must be considered and accounted for.
- Behavioural monitoring of agents with alerting configured to produce warning when agents are going off script.
- Logging of agent actions and decisions.
- Sandboxing of agents and environments; especially when performing sensitive actions such as code execution.
- Rate limiting to prevent DoS and denial of wallet attacks (setting hard limits for token usage can also help but may inadvertently result in a DoS if an attacker or rogue agent exhausts the token supply).
- Third party security assurance of the design and implementation (AI/ML SDLC Assessments).