AWS (Amazon Web Services), Microsoft, and Google now offer some serious control planes for building and governing autonomous AI agents.
AWS Bedrock AgentCore favors modular, deterministic control
Amazon Bedrock AgentCore separates runtime, memory, identity, gateway, policy, registry, browser, code execution, and observability into services that can work together or independently. It supports multiple models and frameworks, making it attractive when we don’t want our agent architecture welded to one model provider. AWS’s AgentCore overview describes isolated sessions, workload identity, Model Context Protocol (MCP) tooling, and policy enforcement at the gateway.
Its sharpest security feature is temporal policy. AgentCore can require a test before deployment, an approval before payment, or block an external call after sensitive data was read. That is more useful than asking a model to remember its manners.
But these controls govern calls traversing AgentCore Gateway. They don’t automatically remove a role or SaaS entitlement at the target. Good MCP security therefore requires closing direct routes around the gateway and applying the principle of least privilege downstream.
Microsoft Foundry brings Entra identity to the agent estate
Microsoft Foundry, formerly Azure AI Foundry, offers managed prompt agents, containerized hosted agents, and ephemeral agents called through the Responses API. Its natural advantage is Microsoft Entra: published agents can receive distinct agent identities, while OAuth on-behalf-of access can preserve a user’s delegated authority. Microsoft’s current Agent Service documentation also covers toolboxes, tracing, evaluation, and Microsoft 365 distribution.
There’s a catch worth underlining. An unpublished agent may use a shared project identity, and Microsoft calls that a broader blast radius. Published agents need their own role assignments, while only some tools currently support agent identity authentication. That makes non-human identity management, privilege drift, and lifecycle ownership operational concerns, not portal checkboxes.
Most importantly, a freshly issued, audience-scoped token may still rely on a permanent Azure role-based access control assignment. The credential is temporary; the entitlement isn’t.
Gemini Enterprise emphasizes cryptographic agent identity
Gemini Enterprise Agent Platform combines Agent Development Kit (ADK), Agent Runtime, Memory Bank, Agent Registry, Agent Gateway, and observability. Google gives each agent a SPIFFE identity and managed X.509 certificate, then uses mutual Transport Layer Security (mTLS) and Demonstrating Proof of Possession (DPoP) to reduce credential theft and replay. Google’s 2026 Agent Identity documentation says raw end-user credentials can remain hidden from the agent.
Agent Gateway applies Identity and Access Management (IAM) policies to registered tools and agents. Semantic governance can also compare proposed tool calls with user intent, although Google labels it Pre-General Availability and warns that its model-generated verdicts can be wrong. Sensible honesty, and a reminder that attribute-based access control must remain deterministic where consequences matter.
Google also notes that deleting an agent doesn’t remove IAM bindings referencing it. Those grants become inactive, not nonexistent—the sort of detail that turns invisible AI trust chains into tomorrow’s audit finding.
JIT security controls authority, not only credentials
“Never send a human to do a machine’s job.”
- Agent Smith, The Matrix [1999].
Fair enough in this day and age. Just don’t send a machine with standing admin access. When we began comparing AWS Bedrock AgentCore vs Microsoft Foundry vs Gemini Enterprise, one notable gap stood out: identifying an agent, authenticating it, and filtering its tool calls aren’t the same as removing its authority when the work ends.
Identity tells us which agent is acting. Authentication proves it. Authorization defines what it may do. Just-in-time (JIT) access decides whether that authority should exist for this task, right now.
Meaningful just-in-time access grants a specific agent narrowly scoped authority after a contextual policy or approval decision, then revokes it after success, failure, cancellation, or timeout. It moves us toward zero standing privileges, rather than continuously renewable short-lived tokens sitting above permanent roles.
NIST’s 2026 agent identity guidance recommends unique agent identities and bounded entitlements, and warns against shared credentials and long-lived bearer tokens. The World Economic Forum found that 87% of respondents saw AI-related vulnerabilities rising, while only 64% assessed AI-tool security. Gartner predicts 40% of enterprises will demote or decommission autonomous agents by 2027 after governance failures surface in production.
Build an access path we can prove
A production agent should begin with baseline read access. A task should identify the resource, operation, initiator, risk, approval, and duration. Policy should grant a temporary target-system entitlement, issue a bound credential, enforce tool and transaction limits, monitor behavior, and revoke access automatically.
In multi-agent workflows, A2A security must also ensure delegated authority narrows at every hop. High-impact changes require fresh approval, not a creative interpretation of last Tuesday’s “yes.” Every decision should preserve evidence for an AI audit.
The three platforms provide strong foundations. Our job is to connect them to AI least privilege, enforce agentic application security beyond the model, and make privilege expire before autonomy becomes an incident multiplier.
Put autonomous access on a shorter clock
Check out our Trustle trial to discover human and agent identities across AWS, Microsoft Azure, Google Cloud, and SaaS; expose standing and unused privileges; and replace permanent access with approved, time-bound grants. The agent platforms decide how agents run. Trustle helps ensure their authority doesn’t run indefinitely.
