A lot ships across the identity platform every month, and most of it lands in the release notes and then quietly disappears. That’s a shame, because some of those changes genuinely move how you manage machine and agentic identity. This series reads the release notes for you and pulls out the parts worth your time.
Key Takeaways:
-
Enforce Model Context Protocol (MCP) policies to limit AI agent execution to specific tools under least privilege access.
-
Issue SPIFFE identities and short-lived tokens to Google Gemini AI agents for verifiable workload security.
-
Edit workload parameters directly in the UI while enforcing least-privilege authenticator visibility.
-
Sync accounts in near real-time between Privilege Cloud and Secrets Manager SaaS to simplify enterprise secrets management.
Once a month, we'll take the features that actually mattered, explain what each one is for in plain terms, and link straight to the docs when you want to go deeper. There's no launch event and no countdown attached to any of this. It is just what changed, with a note on why you might care.
Most of what follows comes back to two shifts. The first is that machine identity is moving away from static secrets you store and rotate, toward workloads that prove what they are and get short-lived credentials on the spot. The second is that AI agents are becoming identities in their own right, things you register, govern, and audit, instead of shadow scripts running around with someone else's token. Almost everything below ties back to one or both of them.
This is the first post in the series, so we're starting with August.
Identity for AI Agents: Governing MCP Tools and SPIFFE Workloads
Most of the agent-side work this month came back to the same underlying thing: giving each agent an identity you can actually govern, and then putting policy and an audit trail around what it is allowed to do.
Access Policies for MCP Tool Execution Onboard Discovered Agents Using an Origin ID
Restrict which tools a given agent is allowed to run, so an agent only gets the tools its job actually calls for.
- What Changed: The policy ties three things together: the users who can start a session, the agents they operate through, and the specific tools on a particular MCP server.
- Why It Matters: If you have watched an MCP server accumulate tools an agent has no business touching, this is the control that reins that back in under least privilege access.
- Module: Secure AI Agents | Released: August 2, 2026 | Read Documentation →
Onboard Discovered Agents Using an Origin ID
When you register an agent, you can now hand an agent its cloud-native identifier during registration to link it back to your existing discovered inventory.
- What Changed: Links a newly registered agent to its cloud-native identifier (such as an AWS ARN or an app ID) matching it to the agent record already sitting in discovered inventory.
- Why It Matters: An agent you found but did not manage becomes one you do manage, collapsed into a single record matched on cloud-assigned identifiers, rather than by hand.
- Module: Secure AI Agents | Released: August 24, 2026 | Read Documentation →
SPIFFE Identities for Google Gemini Enterprise
Issue SPIFFE identities to agents running on the Google Gemini Enterprise Agent Platform (formerly Vertex AI).
- What Changed: Secure Workload Access issues unique, verifiable SPIFFE identities and short-lived tokens to Gemini agents, with trust domains and policy managed centrally.
- Why It Matters: This is where the machine-identity story and the agent story become the same story—an agent is a workload, and here it finally gets a verifiable workload identity and short-lived tokens in place of static credentials.
- Module: Secrets Manager SaaS (SWA) | Released: August 10, 2026 | Read Documentation →
Managing Workload Identity: Friction-Free UI Edits and Least Privilege
The other side of the platform is the workloads that are not agents, the containers and services and jobs that make up most of what actually runs. As more of them carry real identity, the day-to-day tooling for managing that identity has to keep pace. Two changes this month are squarely about that.
Edit Workloads from the Workloads Page
Edit an existing workload in place directly from the Workloads page without tearing it down and recreating it.
- What Changed: Allows updating a workload's method, restricted IP addresses, key-value pairs, and safe access directly in the UI. Name and branch stay read-only.
- Why It Matters: Managing workload identity at scale is mostly an accumulation of small frictions like this one. Clearing them out is how the whole thing stays usable.
- Module: Secrets Manager SaaS | Released: August 30, 2026 | Read Documentation→
Restricted Authenticator Visibility for Workloads
Restrict configuration details for authenticators where you do not have explicit permissions.
- What Changed: Authenticators without permission now show only their type and Service ID on the Workloads page and in API responses (where all configuration detail was previously visible).
- Why It Matters: Holds the control plane itself to least privilege, so that seeing how a workload authenticates takes the same permission that using its secrets does.
- Module: Secrets Manager SaaS | Released: August 30, 2026 | Read Documentation →
Making Secrets Easier: UI Cleanup and Real-Time Account Sync
The through-line for the rest of the platform is the same as it has been for a while: fewer secrets where you can get away without them, and less friction on the ones you cannot. Identity where you can, secrets where you must. Both changes this month chip away at the friction side.
Delete Unmanaged Secrets from the UI or API
Admins can now delete unmanaged secrets directly from inside Secrets Hub.
- What Changed: Synchronously deletes unmanaged secrets via the UI or API without dropping into a vendor console or handing cleanup off to someone else.
- Why It Matters: The deletes are synchronous, so you get confirmation right away instead of firing off a request and hoping it took.
- Module: Secrets Hub | Released: August 4, 2026 | Read Documentation →
Event-Driven Account Sync from Privilege Cloud, with Lower Latency
Push account changes from Privilege Cloud to Secrets Manager SaaS shortly after they happen.
- What Changed: Account creations, property updates, deletions, and password rotations coming from CPM and the Secrets Rotation Service (SRS) now sync automatically. (Rollout reached all regions in August, finishing with us-east-1).
- Why It Matters: A secret read from Secrets Manager SaaS now reflects changes made in Privilege Cloud in close to real time, rather than after the next sync cycle, streamlining secrets management.
- Module: Secrets Manager SaaS | Released: August 5, 2026 (Regional rollout completed Aug 31) | Read Documentation →
See What Else Is New Across the Idira Identity Security Platform
This series only covers the changes worth your time. For everything that shipped, across all identity security, covering humans, machines, and agents, check out the Idira What's New feed for the full, always-current list. Be sure to follow it so the next release doesn't slip past.
FAQs
What is the Idira Technical Insights series?
What is the Idira Technical Insights series?It is a monthly roundup of what actually shipped across the Idira identity platform for machine and agentic identity. Each post explains what a feature is for in plain terms and links straight to the docs. No launch event, no countdown, just what changed and why it might matter to you.
What does "identity where you can, secrets where you must" mean?
It is the guiding idea behind the platform. Use verifiable cryptographic workload identity as the default, so a workload proves what it is and receives short-lived credentials on the spot, and fall back to managed secrets only for the targets that still require them. Several August changes reduce the friction on the secrets side while the identity side keeps expanding.
What is SPIFFE?
SPIFFE, the Secure Production Identity Framework For Everyone, is an open standard for giving workloads a verifiable identity. Instead of handing a workload a stored secret to guard, SPIFFE issues it a short-lived, cryptographically verifiable identity document that proves what the workload is. Secure Workload Access is built on SPIFFE, and the August release extends it to agents on the Google Gemini Enterprise Agent Platform (formerly Vertex AI), so each agent gets a SPIFFE identity and short-lived tokens in place of a static credential.
What do the new access policies for MCP tool execution control?
They control which tools an agent is allowed to run on a given MCP server. A policy ties together the users who can start a session, the agents they operate through, and the specific tools those agents can call, so an agent only gets the tools its job actually needs. If an MCP server has accumulated tools an agent has no business touching, this is the control that reins that back in.