3.0.0-beta.1 (2026-08-24)

Features Added

• Added distributed tracing support.

Breaking Changes

• The Agent optimization-related classes were renamed

Bugs Fixed

• Fixed listing of Agent Optimization Jobs.
• Fixed the StopSession and StopSessionAsync calls.

Other Changes

• Updated the OpenAI package dependency to 2.12.0.

Sample Updates

• Added sample demonstrating disabling and enabling Hosted Agent.
• Added samples for Agent optimization jobs.
• Added sample for creating Agent version drafts.

This is a servicing release of Windows Package Manager v1.29. If you find any bugs or problems, please help us out by filing an issue.

New in v1.29

New Feature: Source Priority

With this feature, one can assign a numerical priority to sources when added or later through the source edit
command. Sources with higher priority are sorted first in the list of sources, which results in them getting put first
in the results if other things are equal.

Beyond the ability to slightly affect the result ordering, commands that primarily target available packages
(largely install) will now prefer to use a single result from a source with higher priority rather than prompting for
disambiguation from the user. Said another way, if multiple sources return results but only one of those sources has
the highest priority value (and it returned only one result) then that package will be used rather than giving a
"multiple packages were found" error. This has been applied to both winget CLI and PowerShell module commands.

REST result match criteria update

Along with the source priority change, the results from REST sources (like msstore) now attempt to correctly set the
match criteria that factor into the result ordering. This will prevent them from being sorted to the top automatically.

Minor Features

Preserve installer arguments across export and import

winget export now captures the --override and --custom arguments that were used when a package was originally installed and saves them into the export file. When subsequently running winget import, those values are automatically re-applied during installation — --override replaces all installer arguments and --custom appends extra switches — so packages can be reinstalled with the same customizations without any manual intervention. Both fields are optional and independent of each other; packages without stored installer arguments are unaffected.

--no-progress flag

Added a new --no-progress command-line flag that disables all progress reporting (progress bars and spinners). This flag is universally available on all commands and takes precedence over the visual.progressBar setting. Useful for automation scenarios or when running WinGet in environments where progress output is undesirable.

MCP upgrade support

The WinGet MCP server's existing tools have been extended with new parameters to support upgrade scenarios:

• find-winget-packages now accepts an upgradeable parameter (default: false). When set to true, it lists only installed packages that have available upgrades — equivalent to winget upgrade. The query parameter becomes optional in this mode, allowing it to filter results or be omitted to list all upgradeable packages. AI agents can use this to answer requests like "What apps can I update with WinGet?"
• install-winget-package now accepts an upgradeOnly parameter (default: false). When set to true, it only upgrades an already-installed package and returns a clear error if the package is not installed (pointing to install-winget-package without upgradeOnly instead). AI agents can use this to answer requests like "Update WinGetCreate" or, in combination with find-winget-packages with upgradeable=true, "Update all my apps."

Authenticated GitHub API requests in PowerShell module

The PowerShell module now automatically uses GH_TOKEN or GITHUB_TOKEN environment variables to authenticate GitHub API requests. This significantly increases the GitHub API rate limit, preventing failures in CI/CD pipelines. Use -Verbose to see which token is being used.

Default priority of installer types

Installer type selection no longer depends on the order defined on the manifest. Instead, preference is given in this order:

• MSIX
• MSI / Wix / Burn
• Nullsoft / Inno / EXE
• Portable

When a user configures installer type requirements or preferences, the order in which they are listed is now respected during installer selection.

Improved list output when redirected

• winget list (and similar table commands) no longer truncates output when stdout is redirected to a file or variable — column widths are now computed from the full result set.
• Spinner and progress bar output are suppressed when no console is attached, keeping redirected output clean.

Log file naming strategy

Added a user setting (logging.fileNameStrategy) for controlling the default naming strategy for installer log files. Supported values are manifest (default), timestamp, guid, and shortguid. Only applies to logs generated by installers if the installer itself supports the logging switch / parameter.

Sortable list output

winget list now supports sorting results via --sort <field> (repeatable for multi-field sorting), --ascending/--descending direction flags, and a persistent output.sortOrder setting. Available sort fields: name, id, version, source, available, relevance. By default, results are sorted alphabetically by name when no query is present; use --sort relevance to preserve the previous source-determined ordering.

Bug Fixes

• winget export now works when the destination path is a hidden file
• Fixed the useLatest property in the DSC v3 Microsoft.WinGet/Package resource schema to emit a boolean default (false) instead of the incorrect string "false".
• SignFile in WinGetSourceCreator now supports an optional RFC 3161 timestamp server via the new TimestampServer property on the Signature model. When set, signtool.exe is called with /tr <url> /td sha256, embedding a countersignature timestamp so that signed packages remain valid after the signing certificate expires.
• File and directory paths passed to signtool.exe and makeappx.exe are now quoted, fixing failures when paths contain spaces.
• DSC export now correctly exports WinGet Admin Settings
• winget validate now performs case-insensitive comparison for file extensions where applicable
• winget source reset now properly resets default sources instead of removing them
• DSC v3 Microsoft.WinGet/Package resource now honors the installMode property to use silent or interactive installer switches as specified
• Fixed a crash (0x8000ffff) when using --disable-interactivity with the Resume experimental feature enabled during install operations.

What's Changed

• Block admin uninstall of user package (1.29) by JohnMcPMS in #6344
• Port scope targeted token check to 1.29 by JohnMcPMS in #6386

Full Changelog: v1.29.280...v1.29.290

It isn’t often that new image formats land in browsers. In the early 2000s we had JPEG, GIF, and PNG. The 2010s gave us WebP, which was a modest step up from JPEG. But the 2020s have given us two new image formats that are a big step up from previous formats: AVIF and JPEG XL.

We shipped AVIF back in 2021, and today we posted our intent to ship JPEG XL. Chrome are also intending to ship, and given there’s already a partial implementation in Safari, the format will be supported across browsers before the end of the year.

Shipping JPEG XL securely

We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox.

So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.

We also pushed for high quality integration tests as part of an Interop 2026 investigation area, and they’re coming along nicely.

Progressive rendering

Although Safari shipped JPEG XL in 2023, their implementation lacked some key features of JPEG XL – our favourite is progressive rendering, which is something we pushed for in the Rust implementation.

Progressive rendering means the image can render as it’s downloading.

Although the full image is 135 kB, with only a few kB downloaded the user can determine the subject of the image. Try the above demo image in a browser that supports JPEG XL & progressive rendering, like Firefox Nightly – move the slider to see how the image displays with just a portion downloaded.

JPEG XL vs AVIF

Browsers will now have two modern image formats for developers to choose from. Which you choose depends on your use-case.

• JPEG XL: Excels at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss.
• AVIF: Excels at web-quality photographic images, and images that have a mix of sharp edges and flat surfaces.

For example:

The image above is a 116 kB AVIF with a quality score (SSIMULACRA 2) of 62.8, meaning medium-high quality. To get the same quality, the JPEG XL image would be 134 kB.

At a SSIMULACRA 2 score of 80 (very high quality), the AVIF is 227 kB, and the JPEG XL is 264 kB.

But at lossless, the AVIF is 1.76 MB, and the JPEG XL is 1.45 MB. A lossless WebP is 1.55 MB.

Another example is a screenshot of the Interop 2025 scores:

At a SSIMULACRA 2 score of 78 (very high quality), the AVIF is 11.6 kB, and the JPEG XL is 23.8 kB.

But at lossless, the AVIF is 164 kB, and the JPEG XL is 92 kB. A lossless WebP is 96 kB.

Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL.

The key is to test with a representative set of images for your site, at a quality that works best for your users, and remember to optimise for high density.

The post Intent to Ship: JPEG XL appeared first on Mozilla Hacks - the Web developer blog.

Distributing API keys to every consumer that needs one is how most teams end up with secret sprawl. A single key gets copied into a shell profile, a .env file, a CI variable, and a shared password manager. Rotate it and something breaks. Revoke a person’s access and the key is still on their laptop somewhere.

Postman Passport takes a different approach. Instead of handing out the underlying secret, it hands out a credential reference: a token that points to a secret without containing it. The real key stays inside your own network, in your secret store. When a request goes through Passport, a proxy running inside your network resolves the reference, injects the actual credential, and forwards the request. The consumer never sees the key.

Postman Passport is available on Postman Enterprise plans with the Advanced Security Administration add-on. See the Postman pricing page for details.

In this post I’ll walk through the architecture: how credential references work, what happens on every request, the security properties Passport enforces, and how teams manage access through namespaces and roles. For the broader “why now” framing, the Postman Passport announcement post covers the product context.

What a credential reference actually is

A credential reference is a token that identifies a secret without containing it. When Passport grants a consumer access to an API, it issues the credential reference. The consumer places the reference into their request wherever the real secret would go. Whether that’s an Authorization header, a query parameter, or a body field, the reference behaves as a placeholder until the proxy resolves it.

References are cryptographically bound to the holder. If someone intercepts a reference in transit or copies it off a machine, it doesn’t work for them. The proxy checks the caller’s cryptographic identity before it resolves anything, and the private key that backs that identity never leaves the holder’s machine. A stolen reference without the matching key is inert.

That is the important shift. In a traditional API key model, possession of the key is authority. Anyone who gets the string can call the API. In the Passport model, the reference on its own has no authority. The authority is the cryptographic identity, and the reference is a pointer that only the identity’s holder can dereference.

The request flow

Here’s what happens when a consumer calls an API through Passport:

1. The consumer sends a request with a credential reference in place of the real secret.
2. The request routes through the secure access proxy running inside your network.
3. The proxy authenticates the caller using a cryptographic certificate.
4. The proxy checks whether the caller’s scope includes the referenced credential.
5. If the check passes, the proxy resolves the secret from your secret store and injects it into the request.
6. The proxy forwards the request to the destination and returns the response.

An example of what the consumer sees might look like this:

GET https://api.internal.example.com/v1/orders
Authorization: Bearer {{passport:cred_orders_read}}

That {{passport:cred_orders_read}} string is the credential reference. On the consumer’s machine, the Postman CLI sends the request through the local access proxy. The destination API sees a normal request with a real Authorization: Bearer <resolved-token> header. The consumer never had the resolved token.

The resolved secret never leaves the proxy. It doesn’t reach Postman, it doesn’t reach the application layer, and it doesn’t appear in any audit record.

The security model

Passport enforces several properties on every request. These are worth understanding because they shape how you reason about what Passport can and can’t protect against.

Identity is cryptographically proven. Each caller presents a certificate to the proxy, and the private key that backs the certificate stays on the caller’s machine. Identity can’t be forged. If a machine is compromised, that machine’s identity can be used from that machine, but identities can’t be lifted and reused elsewhere.

Scope is checked before resolution. The proxy verifies that the caller is authorized for the referenced credential before it contacts your secret store. If a caller tries to resolve a credential outside their scope, the proxy rejects the request without ever touching the store.

Secrets are resolved inside your network. The secure access proxy runs in the same private environment as your services. Secrets get read from your store, used to sign the outbound request, and then discarded. They don’t transit the Postman cloud, and they aren’t written to logs or audit records.

Passport uses your certificate authority as the trust root. Postman authorizes who can be issued a credential reference, but the certificates that prove caller identity are signed by your key. Team Admins can revoke access from your Private API Network at any time.

For teams in regulated industries like finance and healthcare, this design matters because it means secrets never cross an external network boundary. Third-party tools that terminate credentials outside your VPC are often disqualified by compliance policy. Passport keeps the resolution inside your network by design, which is one of the main reasons it fits into environments where other options don’t.

Team workflow: namespaces, managers, and members

Passport uses two roles inside a namespace to control who can add APIs and who can consume them.

Namespace Manager. Approves or denies workspace addition requests and API usage requests, and maps credential references to workspace environment variables. A Team Admin assigns this role.

Namespace Member. Can request to add a workspace so its APIs become available to others, or request access to an API they want to consume.

A typical setup flow looks like this:

1. A Team Admin sets up the access proxy in Postman.
2. The Team Admin creates a namespace and adds Namespace Managers and Namespace Members.
3. A Namespace Member who produces an API requests to add their workspace to the namespace.
4. A Namespace Manager approves the workspace request and maps credential references to the workspace’s environment variables.
5. A Namespace Member who wants to consume an API requests access through the namespace.
6. A Namespace Manager approves or denies each usage request.
7. Approved Namespace Members connect to the access proxy from their machine using the Postman CLI.
8. Approved Namespace Members send authenticated requests with their credential references.

Because access is granted per API and can be revoked at any time, you can offboard someone from a specific API without touching any other credential they hold. The reference stops resolving. There’s no key to rotate on the consumer side and no downstream distribution list to update.

Where Passport fits with your existing setup

Passport doesn’t replace your secret store. It sits in front of it. If you already use HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or 1Password, the proxy resolves references against your existing vault of record. Rotation policies, audit trails, and access policies inside your vault continue to apply. Passport adds a distribution layer that keeps consumers from ever seeing the resolved values.

The consumer-side integration is the Postman CLI. Namespace Members connect the CLI to the local access proxy once, then call APIs from collections that reference passport variables the same way they’d reference any Postman variable. If you’re already writing test scripts that read environment values with pm.environment.get, you don’t rewrite them for Passport. The reference gets resolved on the way through the proxy.

What this changes in practice

The part I keep coming back to is offboarding. In a static-key world, revoking access means rotating the key and updating everyone who legitimately still needs it. If you missed a copy of the key in someone’s dotfiles, you find out when your monitoring picks up a call from a laptop that shouldn’t have one. With credential references, revoking access is a database write in your Private API Network. There’s no lingering copy of a secret on a former user’s machine, because there was never a secret on their machine to begin with.

The other thing worth noting is that this model works the same way for AI agents as it does for people. An agent running against an API through Passport gets a credential reference bound to its identity, with a scope you approved. When the agent is done, its identity is revoked and every reference it held stops resolving. You don’t have to trust that an agent’s process cleaned up its memory or logs, because it never had the secret to clean up.

Try it out

If you’re on the Postman Enterprise plan with the Advanced Security Administration add-on, the natural place to start is registering an access proxy and setting up a namespace with one API you’d like to onboard. Pick something with a static bearer token that a handful of consumers use today, since that’s the case Passport was designed to replace first.

If you’re evaluating whether Passport fits your architecture, the questions I’d start with: which of your APIs currently distribute static keys to consumers, and what would offboarding one of those consumers look like today? The APIs where the honest answer is “we’d probably miss a copy on someone’s laptop” are the ones where Passport pays for itself first.

Resources

• Postman Passport announcement post on the Postman blog
• Postman Private API Network overview
• The Postman CLI overview
• Postman vault offerings
• OWASP Secrets Management Cheat Sheet for wider context on secret management practice
• Postman Enterprise pricing and plans

The post How Postman Passport keeps API secrets inside your network appeared first on Postman Blog.

During my time at AWS, I have always looked for opportunities to work with students. I have delivered over 50 talks at universities across the region, and watching the potential in the room is always a strong motivator. It reminds me of why I do this work, and that the students I meet today may well become our customers and collaborators tomorrow. That is why I am happy to open this week with Student Rewards on AWS Builder Center.

Rick Suttles published Introducing Student Rewards on AWS Builder Center, a new benefit for verified higher education students. When you verify your enrollment through SheerID and complete your Builder Center profile, you unlock 12 months of premium AWS Skill Builder access (900+ courses, hands-on labs, certification exam prep, and game-based learning). From there, you earn badges through actions on Builder Center: publishing articles, commenting, and maintaining engagement. At 7 badges, you unlock $10 in AWS Credits. At 14 badges, another $20 in credits. At 21 badges, you earn an AWS Foundational Certification exam voucher ($100 value).

This represents a commitment of over $500 million in resources during this back-to-school season, providing students with the training, tools, and certification needed to start building their careers in cloud and AI. Student Rewards is available to students 18 years or older and enrolled at accredited higher education institutions worldwide, subject to verification and applicable terms.

Verify your student status and start learning, earning badges, and unlocking rewards!

Last week’s launches
Here’s what else happened this week.

• A new AWS Local Zone in Las Vegas, Nevada – This new Local Zone supports Amazon EC2 C7i, M7i, R7i, and C8gn instances, Amazon EBS, Amazon ECS, Amazon EKS, Application Load Balancer, and AWS Direct Connect. AWS Local Zones are now available in more than 30 metropolitan areas worldwide. In addition, AWS added a fourth Availability Zone to the Europe (London) Region, delivering next-generation AI and ML capacity with Trn3 and P6 accelerated instances alongside general-purpose compute.
• Amazon EC2 Auto Scaling now supports batch instance termination – You can now pass up to 100 instance IDs to the TerminateInstanceInAutoScalingGroup API to terminate them as a batch, reducing the number of API calls needed to scale down your Auto Scaling groups. Batch termination is designed for workloads that need to rapidly scale down, such as AI/ML training jobs, container orchestrators, or event-driven architectures that spin up large fleets temporarily.
• AWS CloudShell now includes a built-in visual file editor – CloudShell now includes a visual file editor that you can launch directly from your shell session using a single edit command. The editor supports syntax highlighting, find-and-replace, multi-line selection, copy-paste, and undo-redo in a single browser session. Whether you are updating a deployment script, modifying an agent steering file, editing a CloudFormation template, or fixing a Lambda function, the editor provides a seamless edit-and-run experience without leaving CloudShell.
• Amazon Bedrock now supports SpaceXAI Grok 4.6 with cross-Region inference – Grok 4.6, a frontier model built for coding, agentic tasks, and knowledge work, is now available on Amazon Bedrock. The model runs on the bedrock-runtime endpoint with support for the Responses, Chat Completions, and Converse APIs, and works with existing account-level controls including model invocation logging, Amazon CloudWatch metrics, and cost itemization in AWS Cost Explorer.
• Amazon Bedrock expands API support and introduces cross-Region inference for OpenAI models – Amazon Bedrock now supports OpenAI GPT-5.6 models (Sol, Terra, and Luna) with the Responses, Converse, and Chat Completions APIs, and adds cross-Region inference. Geo cross-Region inference routes requests within a predefined geography (including new US Geo support with this launch), while Global cross-Region inference serves requests from any commercial AWS Region at a lower per-token cost.
• AgentCore payments is now generally available in Amazon Bedrock AgentCore – At general availability, AgentCore payments includes Quick Create for Coinbase credential provisioning directly within the AgentCore console, a curated Coinbase Bazar MCP server of pay-per-use x402 endpoints via AgentCore gateway, support for the Machine Payment Protocol (MPP), and the “upto” scheme in the x402 protocol for pay-per-inference and dynamic pricing use cases. To learn more, visit the AI Blog post.
• AWS Glue 6.0 delivers 30% price reduction and Iceberg v3 support – AWS Glue 6.0 is built on a fully modernized runtime, Apache Spark 4.1, Python 3.13, and Scala 2.13, delivering 30% lower pricing than previous AWS Glue versions. With Iceberg v3, Glue 6.0 adds the VARIANT data type with automatic shredding for faster reads on semi-structured data, deletion vectors for high-performance row-level updates, geometry and geography data types for spatial processing, and flexible schema evolution.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional posts you may find useful:

• Updates to your AWS Sign-In experience – AWS is gradually introducing updates to the sign-in and sign-up experience. The redesigned sign-in page introduces a unified email entry point for root users and customers using the new email-based sign-in method, while IAM users continue signing in with their account ID, username, and password. The page also includes sign-in options for customers whose AWS account was created using a supported identity provider (Google, GitHub, Apple, or Amazon.com). A redesigned session selection page simplifies viewing and managing multiple active account and role sessions. If your organization relies on browser automation or scripted workflows that interact with the sign-in page, review the post to understand how these changes might affect your configuration.
• In the works: AWS Builder Lofts in Berlin, Hyderabad, and São Paulo – My colleague Channy announced plans to open new Builder Lofts in three cities. Since the first Builder Loft opened in San Francisco in July 2025, it has welcomed more than 22,500 developers through its doors. Each new location will be a permanent community space offering free workshops, networking events, pitch nights, content creation spaces, and co-working areas. Berlin will focus on digital sovereignty and security-readiness, Hyderabad on AI and cloud-native architecture, and São Paulo on supporting Latin America’s developer ecosystem.
• AWS and Amazon WorkSpaces recognized as a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service – AWS has been named a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) for the third consecutive year, evaluated on Completeness of Vision and Ability to Execute. Gartner noted strengths in operations, geographic strategy, and overall viability. This is also the first year the evaluation includes Amazon WorkSpaces for AI agents, a capability that runs AI agents within the same desktop environment, security perimeter, and audit trail as human users.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

• AWS Summits – Free in-person events for builders and innovators to learn, connect, and explore the latest in cloud. Coming up: Zurich (September 2), São Paulo (September 3), Tel Aviv (September 10), and Dubai (September 30). You can also watch keynotes and sessions on the AWS Summits Global Livestream + On-Demand Hub. To access live and on-demand content for a particular Summit, you need to be registered for that event.
• AWS Community Days – Community-led conferences planned and delivered by community leaders. Upcoming events include Bolivia, Santa Cruz (August 29), Toronto, Canada (August 29), JAWS SONIC, Tokyo (September 5), Warsaw, Poland (September 8).

Visit the AWS Builder Center to meet other builders, contribute solutions, and find resources that help you keep building.

Summer is slowly coming to an end, and I am already planning a few days off in the coming months to keep me motivated through the rainy autumn ahead. I hope you are doing the same. Come back next week for more!

To keep pace with modern business, data strategy is shifting toward more autonomous real-time systems that deliver intelligence at the moment decisions are made. Driven by agentic AI, modern data teams are moving beyond simply looking at what happened. Now they’re automating complex workflows that analyze what’s happening, anticipate what might happen next, and recommend or take action.

In this article, I’ll define some of the top trends defining this era, from data agents and semantic layers to hybrid data architectures and next-generation data governance.

Putting data agents to work

Data agents are AI-powered software agents that access governed enterprise data and tools to answer questions and perform defined tasks. Instead of navigating reports and filters, a user can now ask, “Why did sales decline last quarter?” and receive an analysis directly. Dashboards remain valuable for monitoring and shared context, while agents handle questions that weren’t anticipated when the dashboard was built. Think of data agents being on different teams, all working together on a specific goal: understanding what’s happening now, predicting what might happen next, and making real-time decisions.

Analytical and organizational agents are designed to help people find trusted information. They can connect to organizational data, answer natural-language questions, analyze patterns, and surface relevant insights without requiring users to manually navigate databases, dashboards, or reports.

Data engineering and governance agents are working hard behind the scenes to prepare, integrate, monitor, and manage the data that powers those insights. Behind the conversational experience, agentic data engineering applies agents to pipeline development and operations: generating transformations, mapping schemas, documenting datasets, monitoring freshness, and suggesting fixes. Agents can automate routine work, while changes to production data contracts, access policies, or business definitions remain reviewable and auditable.

But remember, data agents are only as good as the quality of the data they’re given. Reliable insights and predictions depend on high-quality, well-governed data. They also need context to understand what the data means, making metadata more important than ever.

Metadata quality is the new data quality

Metadata sits at the epicenter of meaning, trust, and discoverability, providing the context that describes and gives meaning to your data. Like a recipe, good metadata brings together several ingredients: clear names and descriptions, shared business definitions, sources and ownership, lineage and relationships, and information about freshness and sensitivity. Leave out too many of those ingredients, and your data agent is left guessing about what the data means and how to use it.

Suppose an agent finds an ARR field showing $5.2 million. The number alone doesn’t tell it how ARR is defined, what’s included in the calculation, which system produced it, or how current it is. Metadata provides that context, helping the agent interpret the metric correctly and explain where the answer came from. Without metadata, $5.2 million is just a number; with it, it becomes meaningful business information.

Good metadata provides essential context, but context alone isn’t enough. Agents also need a consistent way to understand how data connects and how the business defines and calculates the concepts behind it. This is where semantic layers, ontologies, and knowledge graphs come in, turning disconnected data and definitions into a shared map of business meaning and relationships that agents can understand and navigate.

Business context becomes the AI interface

Giving an agent access to data doesn’t mean it understands the business. Semantic models and ontologies or knowledge graphs provide two complementary layers of context that help bridge that gap.

A semantic model provides analytical meaning, defining approved metrics, dimensions, calculations, hierarchies, and relationships. If a sales leader asks, “How did ARR change in EMEA last quarter?” the semantic model can provide the approved ARR calculation, governed EMEA hierarchy, and company fiscal calendar rather than leaving the agent to infer them from raw tables.

Ontologies and knowledge graphs provide entity meaning, helping an agent understand how real-world concepts such as customers, contracts, products, employees, and organizations relate across different systems. For example, the same customer might appear under different identifiers in a CRM, billing platform, and support system; an ontology or knowledge graph can help establish that these records represent the same business entity and define how that entity relates to others.

Together, they give agents both analytical and organizational context: The semantic model helps explain how the business measures something, while ontologies and knowledge graphs help explain what things are and how they relate. That distinction matters because an agent can generate perfectly valid SQL and still deliver the wrong business answer if it chooses the wrong metric, entity, relationship, time period, or level of detail.

Once agents understand what data means, the next challenge is giving them a consistent, controlled way to access and act on it.

Protocol-first data access (MCP and co.)

Organizations are beginning to give AI agents access to governed data and actions through standardized interfaces, reducing the need to build a custom integration for every agent or application. MCP (Model Context Protocol) is one emerging example, allowing compatible AI clients to discover and invoke defined tools. For example, a data platform could expose tools that let an agent find a certified dataset, retrieve a metric definition, inspect a schema, or run an approved query. This makes connecting AI to enterprise data more scalable, but the protocol is only the connection layer; semantics, governance, permissions, and security still need to be designed and enforced separately.

A protocol-first approach can reduce duplicated integration work and create explicit contracts around what agents are allowed to do. It can also make authentication, governance, and observability more consistent across integrations while making it easier to replace or add AI clients and tools without rebuilding every connection from scratch.

Standardizing access makes connection easier, but it also raises a critical question: When an agent acts, whose identity and permissions apply?

Identity passthrough becomes the make-or-break for enterprise AI on data

As AI agents gain access to enterprise data, their permissions need to reflect who or what they are acting for. For user-initiated requests, agents can use delegated access so that existing user permissions continue to apply. Autonomous agents may instead use their own identity, scoped according to the principle of least privilege.

In either case, agents should only be able to access the data and actions required for their task. Identity-aware access helps prevent overexposure of sensitive data while providing the foundation for effective auditing and governance.

When implemented correctly, identity passthrough can preserve existing access controls through the agent layer. But as agents delegate work across tools, services, and other agents, identity can drift or disappear, making it critical to preserve the correct principal and permissions at every handoff.

The access layer is evolving, but so is the underlying data architecture itself.

Open table formats: From storage to catalogs

Open table formats such as Apache Iceberg, Delta Lake, and Apache Hudi are making it easier for multiple engines and tools to work with the same underlying data, reducing dependence on a single data platform. For example, an organization can store data once and make it available to multiple compatible analytics and AI tools rather than maintaining separate copies.

As data becomes more portable, differentiation moves up the stack. The catalog increasingly becomes the control plane for discovering data, tracking lineage, applying governance, and determining how AI systems can access it.

As AI becomes a new consumer of enterprise data, the catalog becomes an increasingly important control point.

Building the foundation for intelligent decisions

Together, these shifts point to a larger transformation: The future of data intelligence depends not only on a single technology but on creating a trusted, connected foundation that AI can understand, access, and act on.

As data intelligence becomes increasingly AI-driven, success will depend on more than simply connecting agents to data. Organizations will need trustworthy context, consistent business meaning, and strong governance behind every answer. For BI teams, that means prioritizing certified semantic models, verified data, and reusable metrics that both people and AI agents can trust.

The future of data intelligence isn’t just about getting answers faster. It’s about building the trusted foundation that allows people and AI to make better decisions together.