{
  "id": 2076047,
  "title": "The Authorization Gap in AI Operations: Building a Policy-Enforced EKS Control Plane with Cedar, Step Functions, and Systems Manager",
  "url": "https://urgent.news/2026/08/20/the-authorization-gap-in-ai-operations-building-a-policy-enforced-eks",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-20T04:51:26.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/pradeep_kandepaneni/the-authorization-gap-in-ai-operations-building-a-policy-enforced-eks-control-plane-with-cedar-1o4k"
  },
  "original_language": "en",
  "account": "The primary challenge in AI-driven operations is not model accuracy for incident diagnosis. The more critical question is who determines if an action is authorized to make changes in production. Model accuracy alone is insufficient to guarantee safe decision-making. Even highly accurate models can sometimes produce incorrect recommendations.\n\nTo address this, the proposal suggests a policy-enforced control plane architecture for EKS (Elastic Kubernetes Service) clusters. The control plane separates the model's recommendation from the actual authorization and execution of the remediation action.\n\nAn executable contract should be established where the AI agent generates a typed remediation proposal with specific details like the action to perform, affected cluster and namespace, workload details, observed and target revisions, reason for the proposal, and execution bounds. This proposal is treated as intent, not fact. The model's suggestion about which revision to roll back should not be trusted without verification from other sources.\n\nA separate evidence collector enriches the proposal with deterministic system data such as deployment generation, current and previous revisions, healthy status of the previous revision, detection of stateful migrations or maintenance freezes, and a timestamp. This provides the necessary facts to make informed authorization decisions.\n\nThe Amazon Verified Permissions with Cedar policies can externalize authorization. The remediation actor can request permission to perform an action against a resource under certain conditions. Policies can be defined to permit actions when specific conditions like previous revision healthiness, stateful migration status, and maintenance freeze are met.\n\nCertain operations should never be allowed to run autonomously, such as deleting persistent data, changing cluster-wide authorization, or executing arbitrary shell commands. These should be explicitly forbidden regardless of the model's confidence level.\n\nAWS Step Functions can manage the workflow state around authorization decisions. The state machine could collect evidence, validate the proposal, classify risk, and decide whether to approve, request human approval, or escalate to a senior engineer. Human approval can be handled using the callback-with-task-token pattern in Step Functions.\n\nIn summary, the key is separating model recommendations from authorization and enforcing policies using Cedar and Amazon Verified Permissions. The control plane determines if an action is authorized to run, while Step Functions handles the workflow orchestration. This keeps policy enforcement focused and separates it from operational risk classification.",
  "summary": "Originally published in AWSBuilder The hardest problem in AI-driven operations is not getting an agent to diagnose an incident. Modern models can correlate logs, metrics, deployment events, traces, Kubernetes state, and historical incidents well enough to produce plausible remediation proposals. The harder question begins one step later: Who decides whether the proposed action is actually allowed…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}