Cubis Engineers

Agentic Engineering

Design AI agents with bounded tools, least privilege, human approvals, and observable recovery.

EngineeringIntermediateUpdated Aug 13, 2026agentsautomationleast-privilegeprompt-injectionobservability

An AI agent can inspect context, choose tools, and take several steps toward an outcome. That makes it useful for repetitive engineering work and risky when its permissions, inputs, or stopping behavior are vague.

Increase autonomy gradually

Level and useControl
Read — explain code or logsRead-only access and source boundaries
Propose — produce a plan or patchHuman review before application
Execute locally — edit files and run testsSandbox, scoped workspace, and command limits
Change shared state — open a pull request or ticketAuthenticated identity, audit log, and explicit scope
Affect production — deploy, delete, message, or change accessHuman approval at the action boundary, monitoring, and rollback

Start at the lowest level that can complete the task. Earn broader autonomy with reliable evaluations and operational evidence, not optimism.

Define the task contract

Before an agent runs, define:

Terminal
Objective: Exact outcome to achieve
Scope: Repositories, services, files, and environments allowed
Constraints: Security, compatibility, time, cost, and policy limits
Tools: Minimum capabilities and permissions required
Approvals: Actions that require a named human decision
Evidence: Tests, outputs, links, and diffs required for completion
Stop: Success, uncertainty, budget, repeated failure, or unsafe state
Recovery: How to reverse changes and preserve useful logs

“Fix the service” is not a task contract. “Identify why staging health checks fail, propose a patch in this repository, run these tests, and stop before deployment” is bounded and reviewable.

Reduce excessive agency

  • expose narrow tools instead of a general shell, arbitrary URL fetcher, or administrator account;
  • give read-only access unless writing is required;
  • use the requesting user’s identity and least-privilege scope;
  • enforce authorization in the downstream service, not in the model’s instructions;
  • require approval for external communication, production changes, deletion, payments, and access changes;
  • limit time, steps, tokens, requests, and spending;
  • log tool calls, inputs, decisions, results, and approvers with sensitive values redacted; and
  • provide a kill switch and tested rollback.

Treat retrieved content as data

Issues, web pages, documentation, code comments, logs, emails, and tool output can contain instructions intended to redirect an agent. This is indirect prompt injection.

Enforce trust outside the model:

  1. Separate trusted task instructions from retrieved content.
  2. Allow only necessary tools and destinations.
  3. Validate tool arguments and model output with schemas and policy.
  4. Do not expose secrets to a context that reads untrusted content.
  5. Require confirmation for high-impact actions even when content claims urgency.
  6. Test the agent with hostile instructions, malformed output, partial failures, and unavailable tools.

Completion requires evidence

An agent is not finished because it says “done.” Require the final diff, commands run, test results, remaining uncertainty, external state changed, and rollback status. Independently check high-impact claims.

The model is not the authorization layer

Prompts can guide behavior, but permissions, policy checks, approvals, limits, and audit logs must be enforced by the surrounding system.

References

On this page