Agentic Engineering Explained: Guardrails That Work

Agentic engineering is building software with AI agents that can plan and carry out multi-step work, such as reading a codebase, editing files, running tests and proposing changes, while humans set the goals and review the results. It is a useful way of working when the agent has narrow permissions and a person approves what matters. It is a risk when the agent can do more than its task needs.

This post defines the term plainly, then sets out the guardrails we think any team should have in place first.

A chat assistant answers a question. An agent is given a goal and a set of tools, then works through steps on its own: it reads files, runs commands, checks the result and tries again. In software work that might mean fixing a failing test, updating a dependency or writing a feature slice.

The shift matters because the agent now acts, not just advises. Actions have consequences, and consequences need limits.

OWASP's LLM06 entry on excessive agency defines the problem as damaging actions performed in response to unexpected, ambiguous or manipulated model output. It applies whatever the cause, whether a hallucination or a prompt injection. OWASP lists three root causes: excessive functionality, excessive permissions and excessive autonomy (OWASP LLM06:2025).

In plain examples: an agent with a shell tool when it only needed to read files, an agent with database write access when it only needed a report, or an agent that deploys without anyone approving.

Start with least privilege. OWASP recommends providing only the minimum necessary extensions, limiting each to the functions it needs, granting downstream permissions at the minimum level and enforcing authorisation in downstream systems instead of trusting the model's decisions. Then require human approval for high-impact actions, and log activity so you can reconstruct events.

OWASP also notes that logging and rate limiting limit damage but do not prevent the problem. They are a second line, not the first.

Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls (Gartner, June 2025). Scope is a common culprit. Teams give an agent a broad mission, then cannot tell whether it is working.

DORA's 2025 findings point the same way. AI amplifies existing practice, and delivery instability rose alongside throughput (DORA 2025 report). Without tests and review, speed arrives with breakage.

Pick one repository with good tests and low business risk. Give the agent read access and the ability to open a change request, not to merge it. Keep secrets out of its reach. Review every change for a month and note what it got wrong. Widen permissions only where the record is clean.

This is slower than turning everything on. It is also how you find out where the agent is reliable. Our team workflow for this is in how to ship software with AI agents, and the accountability side is in who answers when AI goes wrong.

If you are hiring a studio that uses agents, ask exactly what the agents can access. Ask us the same question and judge the answer.

Write it as a short table that anyone on the team can read in a minute. List the actions an agent might take, then say whether it may do them alone, needs a person to approve or may not do them at all. The policy below is a starting point and should be tightened for payments, personal data and anything customer-facing.

Review the policy after every incident and every quarter. Permissions tend to creep upward because it is convenient, and the review is how you push them back down.