As AI agents become the main engine behind automation and act on behalf of unidentified humans, Boston-based Proof has launched an open protocol intended to help websites and APIs verify the identity and authority behind AI agents performing those actions.
\n\n\n\n
The protocol, called x401, enables services to request credentials confirming information such as identity, organizational affiliation, signing authority or other trusted claims before allowing an AI agent to complete an action. Proof said x401 is issuer-neutral and allows organizations to determine which identity providers and assurance levels they will accept.
\n\n\n\n
The company said x401 was developed with contributors from the payments, identity and AI sectors and will be submitted to the FIDO Alliance’s agentic authentication standards workgroup. The protocol is intended to complement emerging standards for agentic payments and digital transactions by providing a standardized approach to authorization.
\n\n\n\n
“AI is making actions and content effortless to generate. Trust will come from knowing who stands behind them,” said Pat Kinsel, founder and CEO of Proof. “x401 gives every service a common way to ask for proof. Proof Digital ID gives people and organizations a high-assurance way to answer—with a signed record of who authorized what.”
\n\n\n\n
The company said developers can begin using the protocol immediately through documentation, sample applications and integrations with AI assistants including Claude and ChatGPT.
\n\t\t
\n\t\t\n\t\n
\n\n\n\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\n\n\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t
\n\t
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n","snapshot_chars":59925,"live_check":"changed"},{"url":"https://eco.com/support/en/articles/15192005-agent-identity-verification-how-ai-agents-authenticate-purchases-in-2026","committed_hash":"sha256:eb6d62669f3e11a9ecc8e56dac2ada414c050abca03dd24ea2acf714097a2e8a","committed_hash_short":"sha256:eb6d6266…097a2e8a","mime_type":"text/html","committed_at":"2026-07-27T05:00:20.568442+00:00","content_snapshot":"Agent Identity Verification: How AI Agents Authenticate Purchases in 2026 | Support
Agent Identity Verification: How AI Agents Authenticate Purchases in 2026
How Mastercard Agent Pay tokens, Visa Trusted Agent attestations, AP2 Verifiable Credentials, and W3C DIDs prove an AI agent is authorized to transact in 2026.
Written by Eco
Table of contents
AI agents now hold payment credentials, browse merchant catalogs, and submit checkout requests on behalf of human principals. The acquirer at the other end of the transaction has a problem no card network was designed to solve: how do you tell a legitimately delegated agent from a scripted attacker reusing a stolen token? Agent identity verification is the layer that answers that question. This article maps the four production approaches shipping in 2026, the consent flow that ties them to a human, and the threat model each is built to defeat.
What Is Agent Identity Verification?
Agent identity verification is the cryptographic process of proving that a software agent submitting a payment is (a) a known agent registered with a network or issuer, (b) currently authorized by a specific human principal, and (c) acting within a scoped mandate. It binds agent, user, and intent into a single signed credential the merchant or acquirer can verify before settlement.
The 2026 landscape splits into four implementation models: tokenized agent identities (Mastercard Agent Pay), attestation headers (Visa Trusted Agent Protocol), Verifiable Credentials with signed mandates (Google's AP2), and decentralized identifiers (DIDs, used by crypto-native agents settling onchain). Each maps to a different trust anchor: card network, acquirer, issuer-signed VC, or self-sovereign DID document.
Existing 3-D Secure flows assume a human cardholder is present at checkout to complete a challenge. An AI agent cannot solve a CAPTCHA, receive an SMS OTP on the user's phone, or pass a biometric prompt. Networks classify agent traffic as card-not-present with no liability shift, which spikes decline rates and shifts chargeback exposure onto merchants. A purpose-built identity layer was required.
Mastercard's own April 2025 announcement framed the gap explicitly: "today's payment systems weren't built for AI agents to transact." Visa's Intelligent Commerce program described a parallel finding, that agent transactions were being blocked by issuer fraud rules trained on human session patterns. Both networks now layer agent-specific identity on top of EMV tokenization rather than replacing it.
How Does Mastercard Agent Pay Encode Agent Identity?
Mastercard Agent Pay issues an Agentic Token through the Mastercard Digital Enablement Service that binds three identities into one credential: the cardholder, the registered AI agent, and the scope of the mandate. When the agent presents the token at checkout, the network verifies the agent's certificate, decrypts the cardholder PAN, and enforces the mandate's spending limits before authorization.
Agents must be enrolled by their developer through Mastercard's program (announced with Microsoft, IBM, Braintree, and Checkout.com as launch partners). Enrollment produces a cryptographic agent ID that the network associates with the developer's KYC'd entity. At checkout, the token carries the agent ID alongside the cardholder token, letting the issuer score risk per agent rather than per session. See our full Mastercard Agent Pay explainer for the token lifecycle.
How Does Visa Trusted Agent Protocol Attest Agents?
Visa's Trusted Agent Protocol takes a different architectural choice. Rather than embedding agent identity in the payment token, it adds signed HTTP headers to the merchant request that attest the agent's identity, the user's consent, and the transaction intent. Merchants verify the signature against Visa's registry before routing the authorization, preserving the existing card rails.
The attestation header carries the agent operator's identifier, a user-consent reference, and a payload hash binding the attestation to the specific cart. Visa published the protocol in late 2025 as an open standard with Adyen, Cloudflare, and Stripe in the early signatory cohort. Because the protocol lives at the HTTP layer, it works with any underlying card brand. Compare the architecture side-by-side in our Agent Pay vs Trusted Agent breakdown.
How Do AP2's Verifiable Credentials Bind User Intent?
Google's Agent Payments Protocol (AP2) uses W3C Verifiable Credentials to make user consent cryptographically auditable. The protocol defines two mandate types: an Intent Mandate, which the user signs to authorize an agent to shop within a scope (e.g., "buy size-9 running shoes under $200"), and a Cart Mandate, signed when the agent presents the final cart for explicit human approval.
Each mandate is a VC issued by a wallet the user controls, signed with the user's key, and presented by the agent to the merchant or payment processor. The merchant verifies the signature and checks the mandate scope before charging. Google open-sourced the AP2 specification with more than 60 launch partners including Mastercard, American Express, PayPal, Coinbase, and Salesforce. For protocol depth see our AP2 protocol explainer.
How Do DIDs Verify Crypto-Native Agents?
Decentralized Identifiers (DIDs), standardized by the W3C in 2022, give an agent a self-sovereign identifier resolvable to a DID document containing public keys and service endpoints. A crypto-native agent settling in stablecoins on Base or Solana can sign a transaction with the key referenced in its DID document, and a counterparty can verify the agent by resolving the DID without consulting a central registry.
DIDs pair naturally with VC mandates: the user's wallet issues a VC delegating spending authority to the agent's DID, and the agent attaches the VC to onchain payments. AP2 explicitly supports DID-anchored issuers and holders, which is why protocols like Coinbase's x402 micropayment standard and Skyfire's agent-payment network use DIDs as the primary identity primitive for autonomous-agent commerce.
Identity Models Compared
The four models differ in trust anchor, transport, and how user consent is captured. The table summarizes the production characteristics relevant for merchants and developers choosing an integration path in 2026.
Model
Trust anchor
Transport
User consent
Best fit
Agentic Tokens (Mastercard Agent Pay)
Card network registry
EMV token in authorization
Tokenization enrollment + mandate scope
Card-rails merchants on Mastercard
Trusted Agent Attestation (Visa)
Visa agent registry
Signed HTTP headers
Consent reference in attestation
Any card brand, HTTP-layer checkout
Verifiable Credentials (AP2)
User wallet (issuer-signed VC)
VC presentation in protocol message
Signed Intent + Cart Mandates
Multi-rail (cards, ACH, stablecoins)
DIDs (W3C)
Self-sovereign DID document
Onchain signature or DIDComm
VC mandate to agent's DID
Crypto-native, stablecoin settlement
What Does the Consent Flow Look Like?
Across all four models the consent flow follows the same three-leg pattern. A human principal authorizes an agent with a scoped mandate. The agent shops within scope and presents a cart. The merchant verifies the agent's identity and the mandate's binding to the cart before settling. The verification step is what each protocol implements differently.
In a typical AP2 + Agent Pay hybrid flow, a user opens a wallet app, signs an Intent Mandate ("$500 monthly grocery budget, only at approved retailers"), and delegates to a registered agent. The agent fills a cart at an enrolled merchant. Before authorization, the merchant requests a Cart Mandate, which the user signs after reviewing the line items. The agent submits the Agentic Token plus the Cart Mandate VC. The issuer validates both before approving.
What Attacks Does Agent Identity Defend Against?
The threat model agent identity verification addresses includes rogue agents (unauthorized agents impersonating a registered one), replay attacks (reusing a captured mandate or token for a second transaction), scope escalation (an agent transacting outside its mandate), and merchant collusion (a merchant fabricating a mandate the user never signed). Each protocol layers defenses against this set.
Agentic Tokens defeat replay by binding each token to a single authorization window and a specific agent certificate. Trusted Agent headers prevent merchant collusion through user-consent references that are independently verifiable. AP2 Cart Mandates defeat scope escalation because the merchant must obtain a freshly signed mandate for each transaction. DIDs defeat impersonation by anchoring the agent's public key in a tamper-evident document the user can revoke. The remaining residual risk is principally key compromise, which falls back on wallet-level protections such as hardware-bound keys, biometric re-prompts, and revocation lists.
How Does Eco Fit Into Agent Identity?
Eco's orchestration layer settles agent payments in stablecoins across 15 chains, which means agents using AP2 or DID-based identity can route a verified mandate to the cheapest execution venue without human intervention. The Eco Routes API accepts a DID-signed payload, validates the attached mandate, and dispatches the transaction through Hyperlane or CCTP rails depending on destination chain.
For builders integrating agent commerce, the practical pattern is: use AP2 mandates for human-to-agent consent, use DIDs for agent-to-agent identity, and use Eco for the stablecoin settlement leg. See the Agent Pay implementation guide for the integration checklist.
Methodology and Sources
This article synthesizes primary documentation from the four protocol families plus the W3C identity standards underpinning them. All claims about partner cohorts, mandate types, and protocol mechanics trace to the original announcements and specifications listed below. Dated stats use Q1 2026 qualifiers where supply or partner counts change weekly.
AI Agent Identity Management in 2026: Standards, Players, and the Governance Gap
MCP OAuth 2.1, MCP-I at the DIF, Microsoft Entra Agent ID - the 2026 standards landscape for AI agent identity is taking shape. Here's what's real, what's missing, and how to evaluate governance today.
The numbers are no longer theoretical. More than 80% of Fortune 500 companies now run active AI agents built with low-code and no-code tools[1], and Gartner projects that up to 40% of enterprise applications will include integrated task-specific AI agents by the end of 2026, up from less than 5% today[2]. Yet the security posture underneath that deployment wave is alarming: on average, only 47.1% of an organization's AI agents are actively monitored or secured[3]. The other half operate without oversight, logging, or identity controls.
\n
This is not a future problem. It is the current state of your production environment.
\n
The good news - if you can call it that - is that the standards community has noticed. In the first half of 2026, more governance specifications landed for AI agent identity than in the entire prior history of the field. This post maps what those standards actually say, which vendor categories are responding, where the real gaps remain, and what a buyer should demand today.
\n\n
The Standards Landscape: What's Actually Shipping
\n
MCP OAuth 2.1 Under Linux Foundation Governance
\n
The Model Context Protocol started as an Anthropic experiment in November 2024. By December 2025, Anthropic had donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation, with OpenAI, Block, AWS, Google, Microsoft, Cloudflare, and Bloomberg joining as founding or platinum members[4]. Within four months, the AAIF grew to 170 member organizations - more than double the membership CNCF had at the same stage of its life[5].
\n
The governance shift matters for enterprise buyers. MCP is no longer a single-vendor protocol that any one company can deprecate or fork. It is now closer in structure to CNCF than to a proprietary API.
\n
On authentication specifically: the MCP spec mandates OAuth 2.1 with PKCE for all protected HTTP-based deployments, requiring HTTPS on all endpoints and discoverable authorization server metadata[6]. The 2026 roadmap, published in March, makes enterprise readiness - including audit trails, SSO-integrated auth, and configuration portability - a top priority. The spec's authorization Working Group had six dedicated sessions at the April 2026 MCP Dev Summit, with the OAuth 2.1 spec author present.
\n
The 2026 MCP roadmap flagged audit trail infrastructure, SSO-integrated auth, and configuration portability as the top enterprise requests[7]. None of those are solved yet. The roadmap is a commitment, not a delivery.
\n
warning Warning
The authentication gap is real. Research published in early 2026 documented more than 1,800 active MCP servers on the public internet with no authentication whatsoever. Because authentication in MCP is optional — not required by the spec — they are technically compliant and practically insecure. Before deploying any MCP server, verify OAuth 2.1 is enabled and enforced, not just installed.
\n\n\n\n
MCP-I / KYA-OS: Decentralized Identity for Agents
\n
OAuth 2.1 handles authentication - proving an agent is who it claims to be. It does not answer the harder questions: Who authorized this agent? What is it allowed to do on behalf of which human? Can a downstream service verify that chain without prior coordination?
\n
In March 2026, Vouched formally donated the Model Context Protocol - Identity (MCP-I) framework to the Decentralized Identity Foundation (DIF), where it is now stewarded by the DIF Trusted AI Agents Working Group[8]. The spec has since been renamed KYA-OS (Know Your Agent Operating System) to reflect its scope beyond MCP alone.
\n
MCP-I / KYA-OS uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to enable cryptographically secure verification of both agents and their human principals - without requiring prior coordination between parties[9]. The framework defines four identity questions every service should be able to answer: Who is the agent? Who authorized it? What is it allowed to do? What is the scope of that delegation?
\n
This is the right architecture for multi-organization agent workflows - a travel booking agent acting on behalf of a user across airline, hotel, and payment systems, for example. It is also early. The spec is in active community development, and production implementations are sparse.
\n
Microsoft Entra Agent ID
\n
Microsoft moved fastest among the major identity platforms. Microsoft Entra Agent ID introduces agent identities as a distinct, purpose-built construct - not a repurposed service principal or user account - with agent identity blueprints serving as templates for creating individual agent identities with parent-child relationships[10].
\n
Agent identities in Entra do not have credentials of their own; they rely on the agent identity blueprint to acquire tokens on their behalf, and they only authenticate using federated identity credentials[11]. This is the right model: credentials live in the blueprint, not on the agent, so a compromised agent cannot exfiltrate its own keys.
\n
Microsoft Agent 365, generally available from May 1, 2026, gives each AI agent its own Entra Agent ID for identity, lifecycle, and access management, and integrates with Conditional Access, identity protection, and Microsoft Purview[12]. Third-party agents from AWS Bedrock, n8n, and other frameworks can be onboarded via workload identity federation - no platform-specific credential management required.
\n
The honest limitation: Entra Agent ID is a strong solution if your agent estate lives inside the Microsoft ecosystem. For organizations running heterogeneous stacks - Anthropic, AWS, open-source frameworks, and custom-built agents - the governance surface extends well beyond what any single IdP can cover.
\n
CSA Agentic Trust Framework and CSAI Foundation
\n
The Cloud Security Alliance has been the most prolific standards producer in this space. The CSA published the Agentic Trust Framework (ATF) on February 2, 2026 - the first governance specification applying Zero Trust principles to autonomous AI agents with a structured maturity model[13]. The ATF was co-authored by John Kindervag, the original creator of Zero Trust.
\n
A companion survey of 285 IT and security professionals makes the urgency concrete: 84% of organizations cannot pass a compliance audit focused on agent behavior or access controls, and only 23% have a formal agent identity strategy[14].
\n
The CSA's MAESTRO threat modeling framework explicitly names agent impersonation as a distinct threat class - malicious actors deceiving users or other agents by impersonating legitimate AI agents. The prescribed mitigations are trusted agent registries, cryptographic agent identities, and short-lived OAuth/OIDC tokens scoped to the intersection of what the agent is allowed to do AND what the delegating user is allowed to do. An AND gate, not an OR gate.
\n
In March 2026, the CSA launched the CSAI Foundation at RSAC 2026, a new 501(c)3 dedicated exclusively to AI security, with a 2026 mission of "Securing the Agentic Control Plane" - governing identity, authorization, orchestration, runtime behavior, and trust assurance for autonomous AI agent ecosystems[15].
\n\n
The Player Map: Four Categories, Different Strengths
\n
The vendor landscape has fragmented into four distinct categories. Understanding what each does - and doesn't do - is essential before buying.
\n
AI Agent Identity: Vendor Category Comparison
Category
Examples
Core Strength
Key Gap
Identity Providers extending to agents
Microsoft Entra Agent ID, Okta (MCP server + Auth for MCP), Auth0
Unified lifecycle governance across human and non-human identities; policy-driven provisioning and deprovisioning; access reviews
Legacy IGA platforms bolt on agent support; depth and automation vary significantly
\n\n\n\n
A few notes on the landscape:
\n
Identity providers are moving fast. Auth0's "Auth for MCP" became generally available on May 6, 2026, and Okta released its own MCP server as a secure protocol abstraction layer enabling AI agents to interact with Okta's scoped management APIs with least-privilege access control enforced at each tool call[2]. These are authentication solutions. They do not govern the full identity lifecycle.
\n
NHI specialists have the discovery story right. Veza's 2026 State of Identity and Access report found that a mere 0.01% of non-human identities control 80% of cloud resources, while the average worker holds 96,000 entitlements[16]. Knowing that is valuable. Governing it requires more than a posture dashboard.
\n
MCP gateways solve the runtime enforcement problem elegantly for agents you build inside their ecosystem. The problem is coverage: only 23.7% of organizations use their existing IAM/IdP as an authorization server for their agentic MCP infrastructure[3]. The rest are running disconnected auth stacks.
\n
IGA platforms are the natural home for agent governance - if they've actually built it. SailPoint expanded Agent Identity Security connectors in 2026 to include SaaS versions of Salesforce, ServiceNow, and Snowflake, but governance of agent identities requires a separate Agent Identity Security license[17]. Legacy IGA vendors are adding agent support as a module. That's not the same as designing for it from the start.
\n\n
The Honest Gaps
\n
Standards are immature. The MCP OAuth 2.1 profile is solid for authentication but has no standardized audit trail format. MCP-I / KYA-OS is in active community development with sparse production implementations. The CSA ATF is a governance framework, not an enforcement tool.
\n
The monitoring gap is severe. Only 14.4% of organizations have achieved full IT and security approval for their entire agent fleet, and 88% of organizations reported confirmed or suspected AI agent security incidents in the past year[18]. Only 21.9% of organizations currently treat AI agents as independent, identity-bearing entities within their security model[3]. Most still treat agents as extensions of human users or generic service accounts.
\n
The over-permissioning problem is structural. 70% of security leaders say AI systems have more access than a human in the same role, and 67% of organizations rely on static credentials for AI systems[19]. Static, long-lived credentials are the opposite of what every framework recommends. They persist after an agent's task is complete, survive offboarding, and create the same orphaned-account problem that has plagued human identity governance for decades - just at machine speed.
\n
The CSA-Oasis State of NHI and AI Security 2026 found that 51% of organizations cite over-permissioned access as a top NHI pain point, and 78% have no documented policy for creating or removing AI identities[20].
\n\n\n\n\n\n
What IGA Looks Like When It's Built for This
\n
The governance problem for AI agents is structurally identical to the governance problem for human identities - and for the same reason that IGA exists: access sprawl, orphaned accounts, over-permissioning, and the inability to answer "who has access to what, and should they?" at any given moment.
\n
The difference is velocity and scale. NHIs outnumber human identities 17 to 1 in the average enterprise, and the NHI population grew 44% year-over-year between 2024 and 2025[21]. AI agents are the fastest-growing segment within that already-exploding category. Quarterly access reviews cannot keep pace. Neither can spreadsheets.
\n
What's needed is a single governance plane that treats human and non-human identities with the same policy engine, the same lifecycle automation, and the same access review workflows - without requiring a separate module, a separate license, or a separate team.
\n
That's the design principle behind Iden. Rather than bolting agent governance onto a human-centric IGA platform, or treating agents as a subset of NHI discovery, Iden governs all identity types - employees, contractors, service accounts, bots, and AI agents - through the same policy-driven lifecycle engine. Fine-grained control at the channel, repository, and project level means an agent gets exactly the access its task requires, and that access is revoked when the task is done. No standing permissions. No orphaned agent accounts.
\n
For organizations evaluating where AI agent governance fits in their stack, the 12 Best IGA Vendors in 2026 post maps the full landscape, and our NHI explosion piece covers the scale of the underlying problem in detail.
\n\n
How to Evaluate Agent Identity Capabilities Today
\n
The standards are immature, the vendor claims are ahead of the implementations, and the threat is real. Here is a practical evaluation framework for buyers.
\n
1
Inventory your agent estate before you buy anything
You cannot govern what you cannot see. Start with a full discovery pass: which agents are running, who deployed them, what credentials they hold, and what systems they can reach. Shadow agents — those with no registry entry, no assigned owner, and no managed identity — are your highest-risk population. Treat them as Critical findings.
2
Demand short-lived, scoped credentials — not API keys
Any platform that relies on shared API keys or long-lived static credentials for agent authentication is not a governance solution. Require per-session ephemeral tokens scoped to the specific task, with automatic teardown at end of session. This is the single highest-leverage control against prompt injection and credential theft.
3
Verify the AND gate, not the OR gate
An agent should only be able to do what the agent is authorized to do AND what the delegating user is authorized to do — not the union of both. Service accounts that inherit broad employee credentials create authorization bypass vulnerabilities. Confirm that your chosen platform enforces the intersection, not the superset.
4
Require a full audit trail at the tool-call level
Logging that an agent 'ran' is not an audit trail. You need: which agent, which user delegated, which tool was called, with what arguments, what data was accessed, and what the result was. The EU AI Act's transparency provisions take effect August 2, 2026. If your platform cannot produce this log on demand, it cannot support compliance.
5
Evaluate lifecycle governance, not just runtime enforcement
Runtime authorization at the tool-call level is necessary but not sufficient. You also need: agent registration and approval workflows before deployment, access reviews on the same cadence as human identities, and automated deprovisioning when an agent is retired. Ask vendors specifically how they handle agent offboarding — most have no answer.
6
Insist on unified governance across human and non-human identities
Separate tools for human IGA and agent governance create blind spots at the seams. An agent acting on behalf of a human should be governed in the same plane as that human — same policy engine, same access review, same audit log. If your IGA platform treats agents as a bolt-on module, you have a coverage gap.
\n\n\n\n\n
The Bottom Line
\n
The 2026 standards landscape for AI agent identity is real and moving fast - MCP OAuth 2.1 under Linux Foundation governance, MCP-I / KYA-OS at the DIF, Microsoft Entra Agent ID in GA, and the CSA Agentic Trust Framework providing the governance vocabulary. These are genuine milestones.
\n
But standards are not implementations. Only 3% of organizations have automated, machine-speed controls governing AI behavior[19]. The gap between what the frameworks prescribe and what organizations have actually deployed is enormous.
\n
The organizations that close that gap fastest will be the ones that stop treating agent governance as a separate problem from identity governance. Agents are identities. They need the same lifecycle controls, the same access reviews, the same deprovisioning workflows, and the same audit trails as every other identity in your environment - just with shorter-lived credentials and faster policy enforcement.
\n
That's not a new category of tooling. It's IGA, built for the full population of identities your enterprise actually runs.
![\"AutomationToday](\"/wp-content/uploads/2023/09/AT_LOG.png\")
![](\"https://automationtoday.net/wp-content/uploads/2026/04/Ad-728x90-1.gif\")
![\"Proof](\"https://automationtoday.net/wp-content/uploads/2026/06/a3-6-27-300.jpg\")
\t\t\t![\"Support\"/](\"https://downloads.intercomcdn.com/i/o/bswxc49x/589158/b7d7ffc062cc9d65848ad33aab14/6fa94b672e312a4371e8e3cecece1edf.png\")
![\"\"/](\"https://eco-c1bf1945b488.intercom-attachments-1.com/i/o/bswxc49x/2405982990/f3213875862a394c11759d745c53/hero_15192005.png?expires=1785130200&signature=906efd396324419a04ff3ddfa6aaa57814fb6a5fb88253e9870a7e6ed97a531a&req=diQnE8B2n4hWWfMW1HO4zdwJ9SIGUou5D9TnwZxbkeLNhEL86EGDTjJoKPGo%0AvOtHEZyNuCnPQGNl6qY%3D%0A\")
![\"Isometric](\"https://aqynbjfkcfnrqkhzbzxl.supabase.co/storage/v1/object/public/cms-assets/5ed37a7f-297e-48c5-b007-40268093b3fa/6c51af9e-cfc7-42f5-958f-0a84c680cb69.jpg\")