## Weekly signal

The useful signal for May 4-12 was not another generic AI warning. It was the convergence of government guidance, cloud platform releases, and standards work around one operating model: AI agents need identity, authorization, data controls, runtime defense, and audit trails.

That matters because agentic systems are no longer just chat interfaces. They can read enterprise data, call APIs, run code, update tickets, trigger workflows, and interact with other agents. In privacy and security terms, the risk is not only a bad answer. The risk is an over-privileged software actor that can combine legitimate permissions in unexpected ways, leak sensitive context, or take actions faster than human review can catch.

## What changed

The biggest policy development came from the Five Eyes cyber agencies. The United States NSA and CISA, Australia’s ASD ACSC, Canada’s Cyber Centre, New Zealand’s NCSC, and the United Kingdom’s NCSC published joint guidance on careful adoption of agentic AI services. The guidance is especially relevant for critical infrastructure and defense, but it is broadly useful for enterprises. It identifies privilege risk, insecure design and configuration, behavior risk, structural risk, and accountability risk. It recommends incremental deployment, continuous assessment against evolving threat models, strong governance, explicit accountability, monitoring, and human oversight.

The practical value of that guidance is that it treats agentic AI as a cybersecurity deployment problem, not only an AI ethics or model-evaluation problem. If an agent has access to sensitive data and tools, its permissions need to be scoped. If it can act autonomously, its behavior needs to be monitored. If it participates in a chain of agents, the organization needs traceability across the chain. If it is embedded in a business process, there must be a clear accountable owner.

Microsoft’s Agent 365 general availability is the clearest enterprise-product response to agent sprawl this week. Microsoft describes Agent 365 as a control plane to observe, govern, and secure agents across Microsoft and partner ecosystems. The May 1 release and related previews focus on agent registry, shadow-agent discovery, management of local and cloud-hosted agents, network controls, Defender-based detection, Entra identity, and Purview data governance. Microsoft specifically calls out risks such as data oversharing, tool misuse, over-privileged actions, unmanaged local agents, and confidential-information access by coding agents.

For builders, the important part is not the Microsoft SKU itself. It is the pattern: agents need to show up in the same operational systems as users, devices, workloads, and applications. If an enterprise cannot answer which agents exist, where they run, what identities they use, which MCP servers they connect to, and what cloud resources those identities can reach, it does not have a defensible agent security posture.

Google Cloud moved in the same direction from the IAM layer. Its May 6 IAM update introduces Agent Identity as a first-class principal distinct from humans and generic service accounts, built on SPIFFE. Google also announced Agent Gateway, Identity-Aware Proxy for Agents, Context-Aware Access for Agents, IAM Allow and Deny support for Agent Identity, Principal Access Boundary preview, VPC Service Controls support for Agent Identity, and an Agent Security dashboard for discovery, vulnerability scanning, runtime threat detection, and graph-based risk discovery. Model Armor coverage now includes protections for prompt injection, tool poisoning, and sensitive-data leakage across agent interactions.

This is a strong privacy signal. Data-loss prevention for agents cannot rely only on scanning final outputs. Agents may retrieve fragments from multiple approved systems and synthesize sensitive conclusions. They may also pass context to tools, third-party endpoints, or other agents. Agent-specific IAM, network gateways, perimeter controls, and runtime inspection are becoming the practical control stack for preventing sensitive-data leakage.

AWS addressed a narrower but important builder surface: MCP-enabled coding agents. The AWS MCP Server is now generally available. It gives AI agents and coding assistants authenticated access to AWS services through a managed remote MCP server, using existing IAM credentials and SigV4 authentication. AWS added IAM context keys, CloudWatch metrics under an AWS-MCP namespace, CloudTrail logging, and a sandboxed server-side Python execution tool with no local filesystem or shell access. AWS also highlights a key control pattern: separate human permissions from agent permissions, so a user can retain broader access while the MCP server is restricted to read-only or otherwise scoped actions.

This matters because MCP is becoming a major tool-integration layer for agents. The security question is no longer whether agents can call tools. They already can. The question is whether tool calls are authenticated, auditable, least-privileged, and isolated from local developer machines. AWS’s design pushes teams toward managed MCP endpoints and away from ad hoc local shell access.

The standards and research community also advanced. OASIS Open announced that the Coalition for Secure AI released two papers: one on agentic identity and access management, and another on agentic security from chatbots to autonomous swarms. The identity paper argues that every autonomous agent needs trustworthy, machine-readable identity, unique credentials, task-limited access, delegation visibility, and continuous verification. The swarm-security paper goes further into harder problems: intent-based authorization, semantic mosaic leakage, ephemeral environments, dynamic credentialing, and Agent Detection and Response.

ServiceNow’s May 5 Autonomous Security & Risk launch shows the same pattern entering security operations platforms. ServiceNow is integrating Armis asset intelligence and Veza permission visibility to govern AI agents, identities, and connected assets. Its framing is direct: every AI agent that acts inside an enterprise does so through an identity, and many enterprises cannot answer who or what has access, why the access exists, and whether it is still valid. ServiceNow also ties agent governance to AI Control Tower, continuous risk scoring, least-privilege enforcement, and traceable audit trails.

## What to do with it

First, build an agent register. Include agents built with internal frameworks, SaaS agents, coding agents, desktop agents, MCP clients, scheduled automations that use LLMs, and agents embedded in vendor tools. For each one, record owner, purpose, environment, model, tools, data classes accessed, identity used, credential lifetime, logging location, and shutdown procedure.

Second, stop treating service accounts as a dumping ground for agent permissions. Where platform support exists, move toward agent-specific identities. Where it does not, create separate workload identities per agent or per narrow agent role. Avoid shared credentials across agents. Use short-lived credentials, scoped OAuth delegation, IAM deny boundaries, and human approval for sensitive actions.

Third, put a policy enforcement point between agents and tools. This can be an agent gateway, managed MCP server, API gateway, service mesh, or broker layer. The goal is to centralize allowlists, deny rules, rate limits, data egress controls, and audit logging. Do not let agents freely edit local MCP configuration, call arbitrary endpoints, or inherit a developer’s full shell environment.

Fourth, monitor behavior, not just access grants. Security teams should log prompts where appropriate, retrieved documents, tool calls, API actions, file access, network destinations, generated code changes, and cross-agent handoffs. Detection rules should look for unusual data aggregation, access to sensitive repositories, privilege expansion, unexpected third-party calls, repeated failed tool calls, and attempts to bypass approval steps.

Fifth, classify agent use cases by data sensitivity and action impact. Low-risk summarization over public or internal non-sensitive data can move faster. Agents touching regulated data, customer records, source code, production infrastructure, payments, or HR decisions need stricter controls: least privilege, human-in-the-loop gates, red-team testing, rollback plans, and incident response playbooks.

The bottom line: the market is quickly standardizing around agents as identity-bearing, policy-governed actors. Builders who design for that now will move faster later. Teams that keep agents hidden inside prompts, plugins, local configs, and shared credentials will create privacy and security debt that becomes painful when auditors, customers, or attackers start asking what the agents actually did.