TL;DR — Key Takeaways
- AI agents are becoming platform users, interacting directly with repositories, infrastructure, deployment systems and operational workflows.
- An AI-native IDP should serve humans and agents through approved APIs, templates, catalogs and machine-accessible interfaces such as MCP.
- Every production agent needs its own identity, tightly scoped permissions and traceable activity rather than shared credentials.
- Prompts are not security controls. Guardrails should be enforced through identity policies, policy-as-code, network controls, sandboxing and approval gates.
- Sensitive actions should require human approval, while lower-risk work can proceed automatically after predefined policy checks.
- Agent workflows need durable orchestration and observability, including traces of tool use, policy decisions, approvals, errors and final system changes.
AI agents are moving beyond code suggestions. They can inspect repositories, open pull requests, query infrastructure, triage incidents, and trigger deployment workflows. That creates a platform engineering problem: An agent acting across production systems needs the same structure, permissions, and operational controls as any other trusted platform user.
An internal developer platform, or IDP, should support both human developers and machine agents. The objective is not unrestricted autonomy, but controlled operation through approved interfaces, reusable templates, and auditable workflows. This requires three foundations: Managed identity, enforceable guardrails, and reliable orchestration.
AI Agents as Platform Users
Traditional developer portals are designed mainly for people clicking through interfaces. AI agents need programmatic access to the same service catalog, documentation, templates, and operational tools. Model Context Protocol, or MCP, provides a standard connection layer between AI applications and external systems, including APIs, databases, and workflow tools.
For platform teams, MCP can expose approved capabilities without giving an agent uncontrolled access to every underlying system. A developer portal can become a machine-accessible control plane where agents query service ownership, discover dependencies, request infrastructure, or launch standardized software templates.
Backstage provides a useful foundation because its software catalog centralizes ownership and metadata for services, websites, libraries, and other components. When agents access that catalog through controlled APIs or MCP tools, they can work with organizational context rather than relying only on a model’s internal knowledge.
Identity and Access Control
Every production agent should have a distinct, traceable identity. Shared API keys make it difficult to determine which agent acted, what permissions it used, or who approved its deployment.
Microsoft Entra Agent ID treats agent identities as dedicated identity objects governed within the same enterprise environment used for other workloads. Google Cloud’s Agent Identity similarly provides each agent with a cryptographic identity and supports access to cloud resources, MCP servers, endpoints, and other agents. Amazon Bedrock AgentCore Identity manages authentication, authorization, credentials, and audit trails for agents accessing AWS or third-party services
The practical rule is simple: apply least privilege. An agent that reviews code should not automatically receive deployment permissions. A deployment agent should be limited to approved environments, repositories, tools, and actions. Credentials should be scoped, short-lived where possible, and connected to clear ownership. Every request should appear in logs under the agent’s identity.
Guardrails Must Sit Outside the Prompt
Prompts are not security boundaries. Instructions such as “do not modify production” can influence model behaviour, but they cannot replace deterministic policy enforcement.
Guardrails should be implemented through identity policies, policy-as-code, network controls, sandboxing, approval gates, and runtime validation. Amazon Bedrock AgentCore, for example, uses Cedar policies to define which principals can invoke specific tools and under what conditions. These policies are evaluated at the gateway, separating authorization from the model’s reasoning.
Kubernetes can provide additional workload isolation through namespaces, role-based access control, and NetworkPolicies that restrict traffic between pods and external systems. High-risk actions, including production changes, data deletion, permission escalation, or security configuration changes, should require human approval. Lower-risk activities can proceed automatically after predefined checks.
Auditability is equally important. The platform should record the agent identity, requested action, tools used, policy decision, output, approval status, and final system change. This allows security and engineering teams to investigate failures and improve controls.
Orchestrating Autonomous Workflows
Useful agents rarely complete complex engineering tasks in one step. They may need to inspect a repository, identify a service owner, create infrastructure, run tests, request approval, and monitor deployment health.
The IDP must preserve workflow state and enforce policy at every stage. Amazon Bedrock AgentCore supports isolated sessions, persistent memory, and built-in observability.
Google’s Agent Runtime provides managed deployment and scaling, while its Memory Bank can preserve selected context across sessions. Kubernetes-native tools such as Argo Workflows can represent multi-step processes as directed acyclic graphs, making dependencies and execution status explicit.
Observability should cover more than uptime. Platform teams need traces of tool calls, latency, errors, token usage, policy denials, approval delays, and task outcomes. Agents should be evaluated like production services: continuously, against measurable reliability and security criteria.
Building the AI-Native IDP
The shift toward autonomous software delivery does not eliminate platform engineering; it makes the platform more important. As PR2Day’s analysis of why AI agents need platform engineering explains, organizations must let agents move quickly without bypassing governance.
A practical AI-native IDP should provide approved tools and templates, unique identities, least privilege access, deterministic policy enforcement, human approval for sensitive actions, durable workflow state, and end-to-end observability.
NIST’s AI Agent Standards Initiative reinforces this direction by focusing on secure, interoperable agents that can act on behalf of users. The organizations that succeed will not give agents the most freedom. They will create the clearest, safest, and most reusable paths for autonomous work.