The cloud API is the contract: how a tool-using operations agent should work

When people picture an AI agent managing cloud resources, they often picture the model "doing" things: logging in, clicking, typing commands. That picture is misleading, and it leads to unsafe designs.

What actually changes a cloud estate is an API call. Create this bucket, with these properties, in this account, under this identity. The cloud provider does not know or care that a language model was involved. It checks the identity, checks the permissions, and does what the request says.

So the right question is not "how much do we trust the model?" It is "what stands between the model's suggestion and the API call?" In a well-built operations agent, the answer is: quite a lot of ordinary, deterministic code. The model proposes. The system decides.

Tool calling, in plain language

Modern language models can be given a list of tools: named operations with a description and a defined set of parameters. When the model decides a tool would help, it does not run anything itself. It returns a structured request: "call create_private_bucket with these values". The application receives that request and decides what to do with it.

That separation is the most important safety property an operations agent has, and many early designs throw it away by giving the model a single tool called something like run_command that accepts any shell or CLI string. At that point the application cannot meaningfully check anything, because every request is a different free-form command. CloudNala's From Chatbot to Agent series covers how tools work in general; this part is about what they should look like when the target is a cloud control plane.

The model's contribution is a proposal: a tool name, some parameters and an explanation. Everything that makes the call safe, correct and attributable is ordinary code that behaves the same way every time, whatever the conversation said.

Ilanga Retail Group is fictional, and its systems and figures are illustrative. For Ilanga's operations assistant, Ops Desk, the model's job is limited to three things: choosing which approved tool fits the request, drafting the parameters, and explaining the plan to the engineer. Everything else happens in code that behaves the same way every time:

Validate every parameter. The bucket name must match Ilanga's naming standard. The environment must be one of dev, test, nonprod or prod. The retention period must be a whole number of days within the allowed range. Encryption and public-access blocking are not parameters at all: the tool always sets them.
Apply the caller's identity. The tool acts on behalf of the engineer who asked, using a short-lived credential for that environment, not a shared all-powerful account.
Check policy and limits. Is this action allowed at this level in this environment, per the authority map in Part 2? Does it need approval? Does the estimated cost exceed a limit?
Call the cloud API. Only now, and only with the validated values.
Record the evidence. Who asked, what the model proposed, what was validated, what policy decided, who approved, what was sent and what came back.

A worked example: one private bucket

Ilanga's stores receive a daily price file. The pricing team wanted a new storage location in AWS for the export, so an engineer asked Ops Desk to create one.

Ops Desk never calls the cloud API on the strength of the conversation alone. The policy service decides whether approval is needed, the engineer approves a specific change rather than a sentence, and only then does validated code submit the request.

The conversation was short. What happened underneath was longer:

The model chose create_private_bucket and proposed a name, the nonprod environment, the pricing team's cost centre and a 90-day retention period, based on what the engineer had said and Ilanga's tagging standard.
The tool rejected the first proposed name because it broke the naming pattern. The model corrected it. This is normal and harmless; validation exists precisely so the model's first draft does not have to be right.
The policy service checked the action against the authority map. Creating a bucket in shared non-production is Level 4 at Ilanga, so it returned "approval required" and the reason.
Ops Desk showed the engineer the exact request that would be sent, the estimated monthly cost and how to undo it. The engineer approved, as a named person, that exact request. If anything about it had changed after approval, the approval would no longer be valid.
The tool submitted the request and received an operation reference, then tracked it to completion. Part 4 explains why that tracking matters more than it seems.
Ops Desk replied with the result and a link to the evidence record.

Nothing in that flow depends on the model being careful. If the model had proposed a public bucket, the tool would not have offered the option. If it had proposed the production account, the policy service would have routed the request differently. If it had tried to call the API without approval, there would have been no credential to do so with.

Design tools around intent, not around the API

A cloud provider's API exposes hundreds of operations with thousands of parameters, because it has to serve every customer. An operations agent's tools should be much narrower, because they serve one organisation's intentions.

Ilanga applied four rules:

One tool per business intent. create_private_bucket, not create_bucket plus put_bucket_policy plus put_public_access_block. The tool does all three in the right order and refuses to do only part of the job.
Safe defaults are not optional. Encryption, logging, tags and public-access blocking are set by the tool, not chosen by the model.
Dangerous variants are separate tools, or not tools at all. Deleting a bucket is a different tool, with a different authority level, and deleting a non-empty one does not exist as a tool.
Descriptions are written for the model and reviewed like code. A tool description tells the model when to use the tool. A misleading description causes wrong choices just as surely as a bug. In MCP-based designs, the description is also part of the security surface, as CloudNala's MCP Without the Hype series explains.

This is the same idea as a good internal platform: give teams paved roads that encode the organisation's standards, rather than raw access and a wiki page of rules.

The policy service is not the model

It is tempting to put the rules in the system prompt: "never create public buckets; always ask before changing production". Prompts are useful guidance, but they are not controls. A prompt can be misread, overridden by a cleverly worded request or simply ignored on a bad day. A rule in code cannot.

At Ilanga, the policy service is a small, separate component that receives a structured description of the proposed action (tool, parameters, environment, caller, estimated cost) and returns allow, deny or approval-required with a reason. Some rules live in Ilanga's own code; others are enforced again by the cloud platforms themselves, through AWS Organizations service control policies and Azure Policy assignments with the deny effect. That duplication is deliberate. If Ops Desk's policy service has a bug, the platform-level guardrail still refuses a public bucket. Teams that already use a general policy engine such as Open Policy Agent can express the agent's rules in the same language as their other admission and deployment rules.

The agent is just one more caller of the platform. It should face the same guardrails as a human engineer, and a few more of its own.

Approval of a sentence is not approval of a change

One of the subtler failures in agent design is approving the wrong thing. If the engineer approves the sentence "create a private bucket for price files" and the agent then constructs the request, the engineer has approved an intention, not an action. Whatever the agent sends afterwards was never reviewed.

Ilanga's rule is that approval binds to the exact validated request: the specific tool, parameters, account and identity. The approval record holds a fingerprint of that request, and the tool refuses to execute anything that does not match. This is the same principle as approving a reviewed pull request rather than a description of one.

Key points

The API call is what changes the estate. Design for what stands between the model and that call.

The model proposes; code decides. Validation, identity, policy, execution and evidence all live outside the model.

Build narrow tools around intent. Safe defaults inside the tool, dangerous variants separate or absent.

Rules belong in code and in the platform. Prompts guide; policy services and cloud guardrails enforce.

Approve the change, not the sentence. Bind approval to the exact validated request.

Next: Part 4, The API call succeeded. The cloud change did not. All parts are on the series page.

How CloudNala can help

We help teams design the tool layer for operations agents: narrow, intent-based tools with safe defaults, a policy service that sits outside the model, approvals that bind to exact changes, and platform guardrails that hold even if the agent's own checks fail. The work usually starts from the changes your engineers already make every week.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Request a Cloud Operations AI Review or write to us at consult@cloudnala.co.za