Skip to main content

ACHIEVE YOUR DIGITAL AMBITIONS

We get our clients from idea to value-creating digital products. Our diverse technical skills are our greatest asset and with over 400 experts we can definitely also help you.

Agentic coding: Is your setup secure before you give the AI agent access?

You have a new colleague in the office. She is tireless, fast, and extremely confident. Agentic coding can feel like having a new junior developer on the team, but she does not behave like the flesh-and-blood kind. So how do you get security under control before handing your new colleague the keys to everything you can access yourself?

There is great potential in agentic coding, but it also comes with risks. Because when we give AI agents access to code, we are effectively also giving them access to a range of systems, decisions, and actions that can have consequences if the setup is not properly secured.

In this blog post, Lead Security Engineer Mads Schaarup Andersen explains where organisations should start before AI agents become a permanent part of the development environment.

Get started!

This may seem like an obvious point, but a surprising number of organisations run into problems because they do not get started in time. As a leader, you can be absolutely certain that employees are already actively using agentic coding, whether you are ready for it or not.

“It is not about painting a frightening picture, but about seizing the opportunity in the fact that you have skilled employees who are already using AI tools. As management, it is your responsibility to communicate the expectations and opportunities. Even if you do not have all the answers yet”

Mads emphasises.

AI policies and threat modelling are processes that will evolve over time. If you decide to build an elaborate framework before involving your employees, you are almost certainly already behind.

“It is not about achieving the highest level of maturity from day one. Ask, build, and adapt. Otherwise, you risk designing a setup that does not actually fit the developers’ workflows”

Mads states.

Understand the threat model

With AI as a partner, we are moving into new territory. And like any explorer, you need to map the terrain you are about to explore. That is why you should start with a threat model: What needs to be protected, who or what could compromise it, and what would the consequences be if that happened?

“Before you let AI loose in your development environment, you need to understand what is involved in an agent-based coding process. Which data flows where, and where in that flow could something go wrong?”

says Mads.

Start by understanding that there are many components at play when you work with agent-based coding. There is the model, the LLM, that you connect to; there are resources in the local environment on the developers’ machines; agent plugins, MCP servers, custom agents, and skills — just to name a few.

By default, the agent may be able to access every part of the setup. But ask yourselves: is that appropriate?

It is also important to think in terms of malicious manipulation. An agent is not only influenced by what the user writes directly. It can also be affected by so-called injection attacks, where malicious instructions are added to the workflow from, for example, a manipulated plugin or a compromised website.

Upskill and involve developers

Even the best rules and security measures only work if developers understand why they exist and how to use them in their day-to-day work. That is why it is the organisation’s responsibility to equip developers to work securely with agentic coding.

And it is absolutely critical to both success and security that developers are involved in the process:

“Your employees are not going to seek out this knowledge on their own. As an organisation, you need to involve and motivate them — and, not least, listen to how developers are actually working with AI.

If you do not ask, incorrect assumptions may lead you to a place where policy and practice live separate lives.”

Mads points out.

This includes teaching developers to recognise risks such as prompt injection, insecure plugins, uncritical package installation, sharing secrets, and overly broad permissions. Use recognised resources such as OWASP, internal guidelines, and concrete examples from your own development environments to make security practical and relevant.

“Give developers access to good security resources so they know how to protect both code and data when AI becomes part of the toolbox”

says Mads.

At the same time, developers should know when to pause and ask for approval — for example, before the agent is given access to new tools, external services, production data, or credentials.

Establish governance and risk management

When AI agents are given access to your development environment, it is not enough to trust that they will behave correctly, or that each individual developer has all the risks under control.

As an organisation, you need to set the framework through governance: clearly defined rules for which skills, plugins, MCP servers, and CLI tools may be used, and how they are installed and managed.

“Make sure you have clear rules and governance in place, so no one can simply install random AI plugins or connect to external services where both trade secrets and personal data could end up being leaked.”

is Mads’ advice.

“It should not be up to each individual developer to assess whether a random plugin, MCP server, or external service is secure enough.”

he adds.

A good rule of thumb is to view the agent as any other part of your software supply chain: it must be assessed, approved, updated, and removable again if it turns out to pose a risk.

Implement security tools and sandboxes

Governance sets the framework. Technical security measures must enforce it in practice.

Use, for example, sandboxes, containers, or isolated development environments so the agent cannot freely read the entire file system, change critical files, or run commands without restrictions.

“Use the built-in security features so AI cannot perform critical actions such as deleting production data. It is easy to overlook, but it can be costly.”

Mads emphasises.

Security scans, agent hooks, and approval gates can help stop risky actions before they happen. This could include requiring human approval before the agent installs packages, changes CI/CD configuration, uses secrets, deletes files, pushes code, or attempts to access production environments.

Security features should not simply be enabled once and then forgotten. They should be tested continuously, so you know whether they actually stop the actions they were designed to prevent.

Summary: Five security recommendations to get you started

Mads’ key point is that agentic coding is rapidly making its way into development environments. In many organisations, it is already in use — perhaps in yours too. That is why the work on security, governance, and risk management cannot wait. Start here:

  • Get started now. Do not wait for the perfect framework. Set the direction, expectations, and boundaries while you learn, and adapt continuously.
  • Start with the threat model. Get an overview of what needs to be protected, which data flows where, which components are part of your setup, and where something could go wrong.
  • Upskill and involve developers. Security needs to fit the way developers actually work. That is why they should be involved from the start — as users, sparring partners, and co-creators of the framework.
  • Set clear boundaries for governance and risk management. It should not be up to the individual developer to assess which plugins, MCP servers, skills, CLI tools, or external services are secure enough.
  • Enforce the framework with technical security measures. Use sandboxes, containers, security scans, agent hooks, and approval gates so the agent cannot freely access files, credentials, production data, or critical systems without control.

Initially, it is the responsibility of the organisation and management to create a secure framework. Not the individual developer’s. Because agentic coding is going to play a bigger role, and the organisations that get started now will be in a stronger position than those that only react once the AI agent has already been given the keys.

Mads concludes with a reminder that not everyone is starting from the same place:

“It is not enough to test on yourself or your three closest colleagues. The security measures need to work for the entire organisation in practice. Not everyone is an AI expert, and we need to be careful of blind spots. That is why it is so important to involve employees from the start.”

Mads concludes.
Lead Security Engineer Mads Schaarup Andersen
Mjølner logo
Privacy Policy
Read more