The demonstration is always impressive. Someone types "create an encrypted storage bucket for the finance exports" into a chat window, and a minute later the bucket exists. The room nods. Somebody asks whether it could also clean up the old test environments, and someone else says "probably, yes".
That second question is where the real design work starts. An assistant that can change a cloud estate is an administrator. It may be friendly and it may explain itself well, but in access-control terms it holds a key, and the fact that it understood the request does not mean it should be allowed to carry it out. A new operations employee who understands every instruction on their first day still does not get the master key to production. Access is earned task by task, environment by environment, with someone checking the work.
This seven-part series is about introducing AI into cloud operations without turning a conversational interface into an uncontrolled administrator. It starts where an organisation should start: with questions, not changes.
Meet Ilanga and Ops Desk
Ilanga Retail Group is fictional, and its systems and figures are illustrative. Ilanga is a Pietermaritzburg-headquartered retailer with 140 stores, mostly in KwaZulu-Natal and Gauteng. A nine-person platform team runs two cloud estates. The online store, and the serverless jobs that move orders and store sales around, run on AWS in the Africa (Cape Town) Region, af-south-1. Corporate systems, the ERP and reporting run on Azure in South Africa North. Changes go through a weekly change advisory board, with an emergency route for incidents.
Ilanga's stores keep trading when power or connectivity drops, buffering sales locally and sending them when the link returns. That is good for customers and hard on the cloud: after a stretch of load shedding or a fibre outage, dozens of stores reconnect at once and flush hours of sales into the reconciliation jobs together.
The platform team's problem was not a lack of tooling. It was time. Engineers spent a large part of each morning answering the same questions: what failed overnight, why did this alert fire, which resources are missing their cost-centre tag, is this bucket really private. Each answer meant switching between two consoles, a log query language for each provider and a runbook wiki. So the team built an assistant in its Teams channel and called it Ops Desk. Its first release could not change anything.
The questions worth asking first
Read-only does not mean trivial. A large share of operations work is finding out what is true, and that is exactly where a language model is useful: it can turn a plain question into the right sequence of queries, read long and noisy output, and summarise it in terms a busy engineer can act on.
Ops Desk's first release covered four kinds of question:
- Inventory and configuration. Which storage buckets allow public access? Which virtual machines in the Azure subscriptions have no backup policy? Which functions are still on a runtime version that is going out of support?
- What happened. What failed overnight? Which jobs retried more than three times? What changed in production since Friday?
- Why an alert fired. Given this alert, what were the related metrics doing, what does the runbook say, and when did this last happen?
- What a policy actually allows. In plain language, what does this bucket policy, role assignment or security group permit, and to whom?
The last category is underrated. Cloud permission documents are precise and hard to read. An assistant that can explain "this policy lets any principal in the organisation read objects under the exports/ prefix, but only from inside the corporate network" saves real time, and the explanation can be checked against the document by anyone who doubts it. In the authority ladder introduced in Part 2, explaining is Level 0 and observing is Level 1. Ops Desk lived at Level 1 for its first month.
How a read-only agent is actually built
The safest version of this assistant is not a model with a broad reader role and permission to run whatever command it likes. It is a model that can choose from a short list of read-only tools, each of which is ordinary code that runs a specific query under a specific identity.
At Ilanga, that meant:
- A reader identity per provider. On AWS, a role whose policies grant only describe, list and get actions on the services Ops Desk covers, plus read access to the relevant log groups. On Azure, the built-in Reader role at the subscriptions in scope, plus Log Analytics read access. Neither identity can write, so no prompt can talk it into writing.
- Named tools rather than free-form commands.
list_public_buckets,recent_function_errors(service, hours),explain_policy(resource_id),changes_since(timestamp, environment). The model picks a tool and fills in parameters; the tool code checks those parameters and runs a query it already knows. - Evidence with every answer. Each reply links to the calls made and the raw records returned. If Ops Desk says three functions failed overnight, the engineer can see the three error records, not just the sentence.
That last design choice matters more than it looks. A language model can summarise forty lines of log output accurately and then, on the next question, state something confidently that the records do not support. The defence is not to hope the model is careful. It is to make every factual claim traceable to a record, so checking is cheap. CloudNala's Agent Evidence Layer series goes deeper on why a trace is necessary but not sufficient.
Read-only is the safest start, not a risk-free one
It is tempting to treat read-only as "no risk". It is not. Reading an estate exposes information, costs money and can mislead.
Five risks came up in Ilanga's design review:
Secrets in configuration output. Function environment variables, connection strings and deployment parameters sometimes contain credentials that should never have been there. A tool that returns raw configuration will happily pass a database password into the model's context and the conversation log. Ilanga's tools redact known secret patterns and named sensitive fields before anything reaches the model.
Personal information in logs. Order and payment logs can contain names, phone numbers, delivery addresses and loyalty numbers. Under POPIA, that is personal information being processed for a new purpose, by a new component, possibly through a model service hosted outside South Africa. Ilanga's log tools use fixed query templates that select operational fields only, and mask the rest. Whether a particular model service may see operational logs at all is a question for the privacy officer, not the platform team; CloudNala's AI and POPIA series covers how to sort the data first.
Queries cost money. Log analytics is usually billed by data scanned or ingested. An assistant that answers "what happened last quarter?" by scanning ninety days of verbose logs can produce a surprising invoice. Each Ilanga tool has a default time window, a maximum window and a cap on data scanned per call.
A confident wrong answer. An engineer who acts on a wrong summary can do as much damage as an agent that acts directly. Evidence links, plain statements of uncertainty ("I found no errors in the last six hours; I did not check before that") and a habit of asking "show me" are the controls.
Reconnaissance. A complete, plain-language map of what is deployed, how it is configured and which permissions are loose is valuable to an attacker. Ops Desk runs under the identity of the engineer asking, scoped to what that engineer may already see, and every question is logged.
None of these is a reason to avoid starting. Each is a reason to build the first release properly.
What Ilanga measured in the first month
Ilanga did not judge the pilot on whether people liked it. It kept a simple record: for a sample of questions each week, an engineer answered the same question manually and compared the results. Over the first month the team checked 200 answers.
Three things came out of that exercise, and they are typical:
- Most errors were scope errors, not reasoning errors. Ops Desk answered the question it was asked about the wrong subscription, the wrong time window or the wrong environment. The fix was in the tools, which now state their scope in every answer, not in the prompt.
- The useful answers were the boring ones. Untagged resources, failed jobs overnight, the meaning of a policy. Nobody needed an assistant to speculate about architecture.
- Engineers trusted answers more when they could see the evidence, and checked them less often over time, which is exactly why the evidence has to stay.
Why not skip straight to action?
Because the demonstration shows the happy path and production is mostly the other paths. A read-only month gives the team things it cannot get any other way: a baseline of what the assistant gets wrong, a list of which questions people actually ask, the tool boundaries that make sense for this estate, and some honest evidence for the next decision. It also builds the habit that every later level depends on: an answer is not trusted because it sounds right, but because it can be traced.
Starting read-only is not timidity. It is how you earn the information you need to grant more authority safely, which is the subject of Part 2.
Key points
An agent that can change the cloud is an administrator. Treat its access the way you would a new employee's, not a chat feature's.
Start with questions. Inventory, overnight failures, alert context and plain-language policy explanations deliver value with no write permission at all.
Build tools, not a shell. Named read-only tools running under a reader identity give the model choices without giving it a free hand.
Every answer carries its evidence. Traceable claims make checking cheap and wrong answers visible.
Read-only still has risks. Secrets, personal information, query costs, confident errors and reconnaissance all need controls in the first release.
Next: Part 2, From read to write: the authority ladder. All parts are on the series page.
How CloudNala can help
We help platform and operations teams work out which questions an operations assistant should answer first, design the read-only tools and identities around them, and set up the evidence and measurement that make the next step a decision rather than a leap. We start from your estate, your runbooks and the questions your engineers already ask every morning.
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