A lot ships across the Idira Identity Security platform every month, and most of it lands in the release notes and then quietly disappears. This series reads the notes for you and pulls out the parts worth your time.
It matters more each month, because two shifts are underway. 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. Second, 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.
For Prisma AIRS customers looking to secure AI agents, the newly generally available Idira integration provides identity controls within their existing AI security platform. Read the launch announcement for details.
Key Takeaways:
- X.509 SVIDs: Secure Workload Access now issues short-lived certificates for mutual TLS and certificate-based access, such as AWS IAM Roles Anywhere.
- Brokered MCP Access: Register Model Context Protocol (MCP) servers without creating OAuth apps by hand, and turn discovered agents into managed identities from the inventory.
- Attestation Without Pre-Placed Credentials: Gemini Enterprise agents attest with Google Agent Identity, and SWA nodes attest on EC2 and Kubernetes with what the platform already provides.
- Easier Secrets Rotation: Rotate Linux credentials without a Windows server, migrate CPM to SaaS rotation, and rotate shared secrets as account groups.
This issue covers September and October together, so the series catches up with the release notes. If you missed it, August covered MCP tool access policies, Origin ID onboarding, and SPIFFE identities for Gemini agents.
Identity for AI Agents: Brokered MCP Access and Google Agent Identity
The agent work over these two months kept closing the same loop: Find the agent, make it a managed identity, and broker what it touches so the audit trail names who did what.
Automatic OAuth App Registration for MCP Servers That Support DCR
Register an MCP server without creating an OAuth app or pasting credentials by hand.
- What Changed: When an MCP server supports dynamic client registration (DCR), Idira registers the OAuth app itself and manages its credential rotation. Agents connect through the Identity Broker without holding MCP server credentials.
- Why It Matters: Every OAuth app created by hand is one more client secret to store and rotate. DCR takes it off your plate, and audits record the user, client ID, agent, tool, and MCP server for every call.
- Module: Secure AI Agents | Released: September 2, 2026 | Read Documentation →
Remediate Unmanaged AI Agent Risk from the Inventory
Close out unmanaged-agent findings from the AI agents inventory in a guided flow.
- What Changed: Register a discovered agent as new (pre-filled with discovered metadata) or link it to an existing managed registration. The risk clears within a few minutes, and a pre-check catches agents already remediated.
- Why It Matters: August's Origin ID linked agents at registration time. This works from the other end: start from the risk finding and turn it into a managed identity.
- Module: Secure AI Agents | Released: September 14, 2026 | Read Documentation →
Google Agent Identity Attestation for Gemini Enterprise Agents
Exchange a Google Agent Identity token for a SPIFFE identity, with nothing installed on the agent host.
- What Changed: A new gemini_enterprise attestor on the SWA Server verifies an agent's Google Agent Identity token and issues a JWT-SVID or X.509-SVID. Verified agents appear in the workload inventory.
- Why It Matters: August gave Gemini agents SPIFFE identities. This version needs no SWA Agent on the host and no key material from you, and the resulting identity works with any SPIFFE-compatible service, not only Google Cloud.
- Module: Secrets Manager SaaS (SWA) | Released: October 13, 2026 | Read Documentation →
Managing Workload Identity: X.509 SVIDs and Simpler Attestation
Secure Workload Access now issues certificates as well as tokens, and its agents can prove where they run without a pre-placed credential.
X.509 SVIDs for Secure Workload Access
Workloads can now get short-lived certificates that carry their SPIFFE identity, alongside JWT-SVIDs.
- What Changed: Each trust domain gets a built-in root certificate authority managed by Secrets Manager SaaS. The SWA Agent renews X.509-SVIDs before they expire, you set the lifetime per trust domain, and the trust bundle is published in PEM, DER, or SPIFFE bundle format.
- Why It Matters: Mutual TLS between services, without running a CA or tracking certificate expiry. With AWS IAM Roles Anywhere, a workload trades its X.509-SVID for temporary AWS credentials, and the role trust policy matches on its SPIFFE ID, so no long-lived access keys sit on the workload.
- Module: Secrets Manager SaaS (SWA) | Released: October 27, 2026 | Read Documentation →
Pro tip: An IAM Roles Anywhere trust anchor holds at most two root CA certificates, and AWS does not refresh it for you. When you rotate the SWA root CA, update the trust anchor before you activate the new CA generation, and don't start a manual rotation while the previous generation is still draining.
Two New Node Attestation Methods: AWS IID and Kubernetes JWT
SWA Agents can now prove where they run using what the platform already provides.
- What Changed: On Amazon EC2, agents attest with the AWS Instance Identity Document, so no certificate needs pre-provisioning. On Kubernetes, k8s_jwt verifies a projected service account token by its signature. Both join x509pop and k8s_psat.
- Why It Matters: A pre-placed bootstrap certificate is the secret-zero problem in a different outfit. And because k8s_jwt checks a signature instead of calling the cluster's API server, one SWA Server can serve many clusters, hub and spoke.
- Module: Secrets Manager SaaS (SWA) | Released: September 2 (AWS IID) and September 10, 2026 (Kubernetes JWT) | AWS IID docs → | Kubernetes JWT docs →
Making Secrets Easier: Organization-Level Onboarding for Secrets Hub
Identity where you can, secrets where you must. On the “must” side, Secrets Hub onboarding moved up a level: you can now bring in whole cloud estates instead of one secret store at a time.
Onboard Azure Management Groups to Secrets Hub
Bring every Key Vault in an Azure management group under Secrets Hub in one step.
- What Changed: Secrets Hub onboards an Azure management group directly, with no need to set up individual secret stores or onboard an entire Microsoft Entra tenant. It creates a disabled secret store for each Key Vault in the group, which you enable in bulk or through the API.
- Why It Matters: Key Vaults multiply as teams add subscriptions. Onboarding at the management group level follows the way the estate is already organized, and nothing goes live until you enable it.
- Module: Secrets Hub | Released: October 12, 2026 | Read Documentation →
Upgrade the AWS Organization Onboarding Template for Secrets Hub
Redeploy the AWS organization template through Connect cloud environments to pick up the latest Secrets Hub improvements.
- What Changed: Secrets Hub now creates and removes secret stores as you add or drop AWS regions in your local policies, supports automated secrets onboarding out of the box, switches authentication to AWS External ID, and restricts network access to specific static IPs.
- Why It Matters: Region changes stop being a manual Secrets Hub task. Mind the deadline: legacy tenant role-based authentication is deprecated in February 2027, and updating through Connect cloud environments moves you to External ID automatically.
- Module: Secrets Hub | Released: September 15, 2026 | Read Documentation →
See What Else Is New Across the Idira Identity Security Platform
A few smaller changes are worth knowing about:
- More regions: Secure Workload Access in Canada (Montreal) and Frankfurt, Secure AI Agents in Frankfurt, London, and Singapore, and the Secrets Rotation Service in Israel (Tel Aviv).
- API rate limits on the Idira Identity gateway: Requests over the limit now get HTTP 429. If your automation is chatty, check which API zone it hits.
For everything that shipped across humans, machines, and agents, follow the Idira What's New feed. And to see why verifiable workload identity is the foundation all of this builds on, read more about Why Cryptographically Verifiable SPIFFE Identity Is Key to Scaling AI Agents.
FAQs
What is the Idira Platform Updates series?
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. This issue covers September and October together.
What is an X.509-SVID, and how is it different from a JWT-SVID?
Both are SPIFFE Verifiable Identity Documents: short-lived, verifiable proof of what a workload is. A JWT-SVID is a signed token a workload presents to a service, which suits API calls. An X.509-SVID is a short-lived certificate with the SPIFFE ID inside it, which suits mutual TLS and any relying party that trusts certificates, such as AWS IAM Roles Anywhere. Secure Workload Access now issues both.
What is node attestation?
Before an SWA Agent can hand identities to the workloads on its node, the SWA Server has to verify the node itself. That check is node attestation. SWA now supports four methods: x509pop, k8s_psat, aws_iid, and k8s_jwt. The two new ones use evidence the platform already provides, so there is no credential to pre-provision just to prove the node is real.
What is dynamic client registration, and why does it matter for MCP?
Dynamic client registration (DCR) is an OAuth standard that lets a client register itself with an authorization server programmatically, instead of an admin creating an app and copying a client ID and secret around. When an MCP server supports it, Idira registers the OAuth app, manages its credentials, and brokers agent access, so the agent doesn't hold an MCP server credential and every tool call is audited with the user and agent behind it.