An agent that changes infrastructure needs three things an auditor will ask for: its own identity, a policy per call and evidence per step. On the example of a co-engineer we define what it may do alone, what it may only propose and what stays blocked.
The agent never writes to the cloud directly. It reads, plans and opens a pull request; approval and apply run through your existing pipeline in Azure DevOps or GitHub, and the model stays on a private endpoint. Every step has a ring that governs it and an article that requires it.
terraform plan, Azure Policy and OPA checks, cost estimate. The plan appears as a comment on the PR.terraform apply with its own managed identity — not the agent’s. Trace, PR, plan and apply log land immutably in immutable storage or S3 Object Lock.The detour through the pull request is deliberate. It separates proposing (agent) from applying (pipeline), makes every change reviewable and uses approval mechanics your team already knows — branch policies and approvals in Azure DevOps, branch protection and required reviewers in GitHub. The same pattern applies to AWS: ecs:UpdateService becomes a Terraform change, not an API call.
An agent on the platform team, with tasks like a new colleague — and with a role model that exists before day one. The table is an excerpt from such a model; which row runs autonomously in your environment is decided by your policy, not by the prompt.
capacity; auto-merge when the policy is met; outside the limits it escalatesSix patterns that vendors now document and that we translate into role models. Each with source and date.
An agent gets its own identity instead of a shared service account: created from a blueprint, with a sponsor as the accountable person, without credentials of its own — tokens run through federated identity credentials. Conditional Access can be applied to every agent of a blueprint; it requires Entra ID P1/P2 and an Agent 365 licence.
Agent identities as workload identities with their own attributes; inbound authentication via JWT, outbound credentials from a token vault. Tools are attached through the gateway via MCP, every call checked against Cedar policies — with separate roles for operating and administering the gateway.
Azure SRE Agent starts with Reader rights and in review mode by default: the agent proposes infrastructure actions, an administrator approves. Autonomy is enabled per response plan or task, not globally; Microsoft recommends two to four weeks of review before individual triggers run autonomously. Missing rights are requested time-limited on behalf of the user.
The agent gets short-lived, read-only credentials and produces a plan; policy as code (OPA, Conftest, Sentinel) checks it for protected resources, IAM, keys and the state backend; a person reviews; a separate CI identity executes the saved plan. What runs is exactly what was approved.
With Azure OpenAI the deployment type decides where prompts are processed: “Global” in any Azure region, “Data Zone EU” only within the EU Data Boundary, “Standard” in the chosen geography. An Azure Policy blocks the GlobalStandard SKU for the whole subscription — blocked, not merely deselected.
Write rights an agent rarely needs are not granted permanently: elevation is time-limited through Privileged Identity Management or the on-behalf-of flow, with a reason and an expiry. The same rule applies to the people who approve agents — reviewing WAF rules does not come with Owner rights.
An agent is as secure as the weakest ring around it. We build five rings from the inside out — from private model access to oversight — and let an agent act autonomously only once all five stand. Every ring has a question the deployer must be able to answer at any time.
Model, prompt and session stay in your environment.
Azure OpenAI or Bedrock in an EU region, connected over a private endpoint or PrivateLink. On Azure, “Global” deployments are blocked by Azure Policy, on AWS global inference profiles by SCP — blocked, not merely deselected. Customer-managed keys, no training on your data, one data processing agreement.
Every agent is its own non-human identity — an agent identity in Entra, an IAM role with AgentCore Identity — with the least rights needed and its own lifecycle. Acting on a user’s behalf, the permission is delegated and expires; a shared service account is not an agent but a risk.
The agent sees only the tools registered in the gateway — MCP servers, connectors, functions — and every call passes a policy: permitted systems, limits, time windows, approval for writes. On Azure through connector DLP and Conditional Access, on AWS in Cedar. The policy lives in code, not in the prompt.
Every tool call, every model response, every approval as a trace with time, identity and result. Export from Application Insights or CloudWatch into your platform — Grafana, Datadog, Dynatrace — with retention under Art. 26(6): at least six months, longer where sector law requires it. Evaluation runs alongside: tool choice, accuracy, aborts.
Named oversight persons with training, a stop switch per agent, an escalation path for exceptions, a change register for model changes and new tools (Art. 25). A report to management whenever model, tools or purpose change — and an evidence file per agent, kept current.
Autonomy is not switched on, it is earned. An agent starts as an assistant in a sealed environment and gains room with every phase — but only once the gate before it has been passed. The gates are evidence, not dates. Whoever does not deliver it stays in the phase.
One use case, one agent, reading and proposing only. Landing zone with private model access is in place (ring 01), the agent has its own identity without write rights (ring 02). AI Act classification and provider/deployer roles are settled. Synthetic and masked data.
Gate A · Classification & identityRisk class documented, role settled, agent in the identity inventory, prompt residency evidenced.Real data, tools in the gateway, every write action waits for a person — review mode. Traces flow into your observability platform (rings 03–04). Evaluation measures tool choice and aborts. The Art. 50 transparency notice is live wherever people talk to the agent.
Gate B · Policy & loggingTool policy in code, trace per call reconstructable, retention configured, evaluation baseline set.Defined actions run without individual approval within limits — instances, systems, time windows. Exceptions escalate to named oversight persons. Stop switch tested. For high-risk classification: Annex IV documentation, FRIA and deployer duties under Art. 26 complete.
Gate C · Oversight & evidenceOversight persons trained, stop exercised, change register active, evidence file per agent created.The agent runs in your operations. Ongoing: evaluation report, policy review, model and tool changes checked against Art. 25, incidents followed up. Every new use case starts again in phase 01 — on the same platform, with the same rings.
Outcome · Operating evidenceEvaluation, policy review and change register, kept current in the evidence file.For agents, classification is not the end but the start: the decisive task is a complete inventory of what the agent does externally — which systems it touches, which data flows, which people are affected. From that follows which article applies and which ring satisfies it.
Secureskies does not provide legal advice. The mapping is our technical reading of the regulation text, the Commission guidelines on Art. 50 and the draft guidelines on high-risk classification of 19 May 2026; borderline cases go to your legal department or law firm. The full classification and the twelve modules that go with it are in the field AI Act & AI Governance.