Apple has just released public betas for iOS 27 and other major OS updates that are set to publicly launch this fall. The big new feature this year is Siri AI, the delayed AI-powered revamp to Siri. It actually works - which is big praise! - though it keeps things brief.

Other betas available now include iPadOS 27, watchOS 27, and macOS 27 Golden Gate. If you want to test out Apple's upcoming updates, fair warning that you may run into issues like unexpected glitches or a battery that drains faster than you're used to. Use your best judgment on whether you should actually install the beta or wait to install an update until it's officially r …

Read the full story at The Verge.

In a series of campaigns observed between mid-2025 and mid-2026, Microsoft identified threat actor activity with overlapping tradecraft commonly associated with ShinyHunters, including voice phishing (vishing), supply chain compromise, and misconfigured guest access to target customer SaaS-based applications such as Salesforce instances. The threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.

Three primary intrusion paths were observed including vishing techniques targeting OAuth consent, supply chain compromise through trusted workflows and integrations such as Salesloft and Gainsight, and exploitation of misconfigured guest access. Abuse of these access paths led to inherited user and application privileges, allowing successful enumeration and querying of customer relationship management (CRM) records while evading conventional authentication detections. These intrusion paths often led to persistent access and exfiltration of data at scale. This tradecraft highlights how a single entry point can rapidly expand to greater enterprise impacts.

Microsoft observed activity associated with these techniques in many tenants from various industries such as retail, education and manufacturing. These findings reinforce the importance of monitoring OAuth-connected applications, validating third-party integrations, reviewing guest access configurations, and enabling Salesforce event monitoring. Leveraging this data, Microsoft consulted with Salesforce to improve granularity in telemetry for Defender for Cloud Apps with near-real-time detection, offering connected application attribution and expanded application permission insights. This activity was not the result of a vulnerability inherent to Salesforce. Rather, the threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.

Attack chain overview

Threat actor campaigns targeting Salesforce customers and using tradecraft associated with ShinyHunters pose a high-impact risk to sensitive data and downstream SaaS ecosystems. These campaigns abuse OAuth trust relationships to operate within pre-existing, legitimate workflows.

Observed activity can be grouped into three primary intrusion paths:

Voice‑phishing-driven OAuth consent abuse

In campaigns beginning in mid-2025, the threat actors conducted vishing attacks impersonating IT support personnel. Threat actors socially engineered employees into authorizing attacker-controlled connected apps within their Salesforce tenant. In several confirmed cases, threat actors guided users through the OAuth consent workflow to grant access to a malicious application disguised as a legitimate Salesforce Data Loader tool. After users granted consent, these highly privileged OAuth applications enabled threat actors to perform API calls on behalf of the victim user, facilitating:

• Enumeration of Salesforce instances belonging to targeted organizations
• Persistent access to Salesforce CRM data
• Possible lateral movement into other SaaS platforms through discovered credentials

This intrusion path exploits the OAuth authorization flow of trusted SaaS services rather than relying on malware or credential replay. Threat actors exfiltrate data through sanctioned application access inherited from user privileges.

SaaS supply‑chain compromise targeting trusted integrations

Following initial access campaigns, threat actors  escalated into supply‑chain-driven attacks targeting third‑party SaaS vendors offering popular solutions that integrate with Salesforce, often using OAuth tokens. In August 2025, compromised Salesloft Drift credentials enabled attackers to obtain connection secrets used by downstream SaaS applications, enabling the use of OAuth tokens in multiple customer Salesforce instances.

A subsequent campaign in November 2025 targeted Gainsight-published applications integrated with Salesforce, allowing attackers to leverage trusted external connections to maintain persistent API access in multiple Salesforce customer instances. These activities often appeared indistinguishable from legitimate integration behavior. Threat actors performed discovery, bulk data queries, and mass exfiltration of sensitive CRM records, including accounts, contacts, and service case data, without generating traditional sign-in anomalies.
More recently, in June 2026, the market intelligence platform Klue experienced an incident where a threat actor, Storm-3138, gained access to its system.  Credentials used to access Salesforce customer instances were used in the same fashion, to discover, query, and exfiltrate data.

Guest access used for exfiltration

Over recent months, Microsoft observed an increase in suspicious guest-user activity targeting Salesforce Aura endpoints across multiple organizations. In these incidents, threat actors leveraged unauthenticated access to Aura framework functionality and used GraphQL-based Aura requests to systematically query and retrieve data. While the activity did not exploit a software vulnerability, it took advantage of misconfigured guest-user permissions to gain unauthorized access to data. By chaining Aura requests and leveraging GraphQL queries, the actors were able to circumvent standard record-retrieval limitations and extract significantly larger volumes of data than would typically be accessible to guest users. All three intrusion paths relied on inheriting trusted application or user privileges, making malicious activity difficult to distinguish from normal operations. The resulting quiet persistence and large-scale data access highlight the need for stronger detection, visibility, and governance of OAuth-connected applications and guest user accounts.

Improving visibility into Salesforce OAuth abuse

For customers using Salesforce Shield: Event Monitoring, the upgraded Microsoft Defender for Cloud Apps Salesforce connector onboards the Real-Time Event Monitoring (RTEM) framework, enabling faster detection and investigation of Salesforce-based attacks.

Investigations into these campaigns exposed a recurring challenge for security teams: malicious activity often appeared indistinguishable from legitimate Salesforce usage because threat actors operated through trusted identities, approved OAuth applications, and authorized integrations. Traditional authentication-focused detections frequently provided limited visibility into the resulting application activity.

To improve investigation and detection of these scenarios, Microsoft expanded Salesforce visibility in Defender for Cloud Apps through additional event telemetry, connected application attribution, and enhanced application permissions insights. These capabilities help security teams identify suspicious OAuth activity, investigate potentially compromised integrations, and better understand how access was obtained and used within customer Salesforce instances.

Key capabilities include:

• Near-real-time visibility into Salesforce security and activity events.
• Connected application attribution, including application identity and granted OAuth scopes.
• Expanded identity, session, and API activity context to support investigations.
• Improved correlation within Microsoft Defender to help identify suspicious activity spanning identities, applications, and SaaS environments.

Together with Salesforce Shield: Event Monitoring, these capabilities help security teams investigate suspicious OAuth activity, validate the legitimacy of connected applications, and better understand the potential impact of a compromise.

New posture and governance capabilities for connected OAuth apps

While improved detection is critical, recent incidents have also highlighted the need for stronger preventive controls and ongoing governance of OAuth-connected applications. To address this, Microsoft Defender introduces new posture capabilities for connected and external client apps in Salesforce. Security teams can gain visibility into each OAuth app and its non-human identity, prioritize risk, and reduce the attack surface.

Deep visibility into app permissions and access

Microsoft Defender provides comprehensive visibility into all Salesforce-integrated connected and external client apps, including granted OAuth scopes and privileges.

Highly privileged apps

Security teams often struggle to identify applications with powerful administrative or sensitive permissions. The highly privileged apps insight highlights applications that have been granted elevated scopes, enabling quick identification of apps that may pose significant risk.

Additionally, security teams can use permission-based filters to identify apps with specific high-risk scopes and validate whether such access is justified.

Unused apps

Organizations often create applications for temporary or one-time use, but those applications are rarely removed afterward. These unused apps continue to retain permissions, creating unnecessary exposure. With the recent changes, Defender now allows security teams to identify applications that have been inactive for extended periods (for example, 90 days or more), making it easy to review and revoke access where appropriate to reduce the attack surface.

Risk-based prioritization of connected apps

To further streamline investigation and response, Defender introduces a comprehensive risk scoring model for connected applications. Each application is assigned a numerical risk score [0-100] based on multiple risk indicators, such as usage patterns, permission sensitivity, and behavioral signals. This allows security teams to prioritize efforts effectively and focus on applications that require immediate attention. Security teams can create custom policies based on risk thresholds to trigger alerts, actions, and notifications.

Risk score investigation

To further investigate the specific Non-Human identity risk details, the factors contributing to the risk score are available in Non-Human Identities Risk score tab.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.  

• Microsoft Defender for Cloud Apps customers can connect their Salesforce instance to get improved visibility and threat detection capabilities.
• Implement best practices as recommended by Salesforce.
• Secure your Experience Cloud Guest User access
• Familiarize yourself with and proactively monitor Salesforce event logs.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections including new detections powered by the upgraded Microsoft Defender for Cloud Apps Salesforce connector. Microsoft Defender coordinates detection, prevention, investigation, and response for endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports 

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer Salesforce instances.

• OSINT Profile: ShinyHunters Calling: Financially Motivated Data Extortion Group Targeting Enterprise Cloud Applications

Advanced hunting

NOTE: The sample queries let you search one week of events. To inspect events and hunt for threat actor-related indicators over a longer period, go to the Advanced Hunting page > Query tab, and use the calendar dropdown to set the time range to Last 30 days (the maximum for raw data).

Hunt for Salesforce connected-app activity from suspicious infrastructure

CloudAppEvents
| where Application == "Salesforce"
| where ActionType in ("ApiTotalUsage", "API Event")
| extend ConnectedAppId = tostring(
    coalesce(
        RawEventData.CONNECTED_APP_ID, // from ApiTotalUsage 
        RawEventData.ConnectedAppId // from API Event
    )
)
| where isnotempty(ConnectedAppId)
| where array_length(UncommonForUser) > 0 // at least 1 attribute is flagged as uncommon

Hunt for API activity associated with connected apps and relevant user ids

CloudAppEvents
| where Application == "Salesforce"
| where ActionType in ("ApiTotalUsage", "API Event")
| extend SalesforceUserId=coalesce(tostring(RawEventData.USER_ID), tostring(RawEventData.UserId))
| extend ConnectedAppName=tostring(RawEventData.CONNECTED_APP_NAME)  // Connected App Name is not available on the ApiEvent event
| summarize count() by AccountObjectId, AccountId, AccountDisplayName, SalesforceUserId, IPAddress, UserAgent, ConnectedAppName

Hunt for anomalous report export / large data access

CloudAppEvents
| where Application == "Salesforce"
| where ActionType  == "ReportExport"
| extend SalesforceUserId = tostring(RawEventData.USER_ID)
| summarize Events=count() by AccountObjectId, AccountId, AccountName, SalesforceUserId, IPAddress, UserAgent

Pivot from a suspicious connected app (name/id) to impacted users and actions

CloudAppEvents
| where Application == "Salesforce"
| where RawEventData has ""
| project Timestamp, AccountId, AccountDisplayName, ActionType, IPAddress, UserAgent, RawEventData
| order by Timestamp desc

Audit queries to verify what objects users are accessing

CloudAppEvents
| where Application == "Salesforce"
| where ActionType == "UniqueQuery"
| extend 
    QueryText = tostring(RawEventData.QUERY_IDENTIFIER), // Full query text
    QueryObject = extract(@"(?i)\bfrom\s+([^\s]+)", 1, tostring(RawEventData.QUERY_IDENTIFIER)), // Extract just the target object
    SalesforceUserId = tostring(RawEventData.USER_ID)
| where QueryText != "SOQL"
| project Timestamp, AccountDisplayName, SalesforceUserId, QueryObject, QueryText

Hunt for users with very high Defender risk score signing into Salesforce

let VeryRiskyUsers = IdentityInfo
| where DefenderRiskScoreNumber >= 90
| distinct AccountObjectId
CloudAppEvents
| where Application == "Salesforce"
| where ActionType has "sso" or ActionType has "saml"
| where AccountObjectId in (VeryRiskyUsers)
| project Timestamp, AccountObjectId, AccountDisplayName, ActionType, UserAgent
| order by Timestamp desc

Indicators of compromise (IOC)

MITRE ATT&CK techniques observed

Initial Access

• T1566.004 Phishing: Voice Phishing: Impersonating IT support to get victims to grant access.
• T1528 Steal Application Access Token: Using stolen OAuth tokens from Salesloft and Gainsight.

Persistence

• T1671 Cloud Application Integration: Leveraging Connected Apps for access to a customer Salesforce environment.

Collection

• T1213.004 Data from Information Repositories: Customer Relationship Management Software: Stealing data from a customer Salesforce environment.

Exfiltration

• T1567 Exfiltration Over Web Service: Usage of the fake Data Loader application to steal data.

This research is provided by Microsoft Defender Security Research, Shruti Ranjit, Doug Cranston, Anand Deshpande, Ronen Rafaeli, and with contributions from members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.

The post Defending SaaS-based applications against ShinyHunters OAuth abuse appeared first on Microsoft Security Blog.

Microsoft Chairman and CEO Satya Nadella took to the internet to share his thoughts about the hidden cost of enterprise AI.

In a lengthy post on X (formerly Twitter) on Sunday, Nadella describes the problem as a “reverse information paradox,” arguing that AI flips Nobel Prize-winning economist Kenneth Arrow’s classic information paradox on its head.

Arrow’s paradox focused on the seller’s dilemma of how to demonstrate the value of information without disclosing it. Nadella argues enterprise AI shifts that burden to the buyer, who must share proprietary processes and institutional expertise to get the strongest results from a model.

“You essentially pay for intelligence twice, once with money, and again with something even more valuable: the proprietary knowledge you must reveal to make that intelligence useful,” he writes. “The better you want the model to perform, the more of that knowledge you have to feed it.”

“You essentially pay for intelligence twice, once with money, and again with something even more valuable: the proprietary knowledge you must reveal to make that intelligence useful.”

When “exhaust” becomes a competitive advantage 

According to Nadella, every engagement with an enterprise AI system generates what he describes as “exhaust” that gradually captures how an organization operates.

“Every correction is distilled into institutional know-how,” Nadella writes. “It’s the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval.”

“Every correction is distilled into institutional know-how. It’s the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval.”

Over time, those thousands of interactions create an internal corpus of organizational knowledge that may be more valuable than the original documents that seeded the system. The more employees use AI, the more an organization’s expertise becomes embedded in how those systems operate.

Redefining the trust boundary 

In practice, those troves of knowledge could push enterprises toward model-agnostic AI stacks in which prompts and memory stores remain under their control — even as the underlying foundation model changes.

In his post, Nadella also took aim at current AI business practices, arguing that model providers claim broad rights to learn from public data while limiting how customers can reuse or build on the knowledge created inside their own organizations.

Some observers may see an irony in the argument coming from Microsoft’s CEO. Nadella warns that enterprises risk losing valuable organizational knowledge to AI systems, yet Microsoft sells Copilot, a product whose value depends in part on wide access to enterprise data. Copilot works by traversing Microsoft Graph, allowing it to reason over documents, emails, chats, and other information that a user is already authorized to access.

Security researchers have raised concerns about the amount of sensitive information such systems can expose if organizations have overly permissive access controls. Research from Concentric AI showed that Copilot accessed nearly three million confidential records per organization during the first half of 2025, while EPC Group audits found that roughly 80% of enterprise Microsoft 365 tenants had significant oversharing risks, including salary information, merger documents, and customer data that could be surfaced through Copilot. The U.S. House of Representatives also banned staff — but later reversed that ban — from using Copilot over data security concerns.

The Microsoft distinction

Microsoft, however, draws a distinction between accessing enterprise data to answer user requests and using that data to train foundation models. The company says information retrieved through Microsoft Graph is not used to train its AI models, and that Copilot respects existing permissions, identity controls, and sensitivity labels.

Still, the commercial strategy here is hiding in plain sight: Nadella’s Sunday “reverse information paradox” post is effectively a roadmap to Azure. Everything Nadella recommends building runs on cloud infrastructure. Essentially, enterprises can swap out the foundation model, but they’re not going to swap out the cloud.

Owning your AI learning loop 

To counter the perceived shift toward giving over information to frontier labs, Nadella outlined several priorities for enterprise AI architecture. Among his recommendations:

• Keeping organizational memory inside the enterprise tenant.
• Building private evaluation and learning systems.
• Decoupling orchestration layers from any single foundation model.
• Preserving the ability to switch models without losing accumulated organizational knowledge.

Taken together, Nadella’s argument comes back to the idea that enterprises should own their learning loop rather than handing pieces of it to the companies that provide their AI models.

Nadella reinforced that idea by quoting Palantir CEO Alex Karp, who has similarly argued that enterprises want complete ownership over their AI infrastructure.

Model-agnostic orchestration emerges 

In the end, by maintaining control over their means of production, enterprises can finally ensure that when they invest in AI, the compounding value stays inside the business where it belongs. Tools like LangChain and Haystack are gaining traction specifically because they let engineering teams treat foundation models as plug-and-play commodities, rather than hardcoded dependencies.

“What the technical customers want is control over their compute, their models, their data stack, and their alpha,” Nadella quoted Karp. “They want to know they own the means of production, and it’s not being transferred to someone else.”

“They want to know they own the means of production, and it’s not being transferred to someone else.”

The post Microsoft CEO Satya Nadella says you’re paying for AI twice — the second price is worse appeared first on The New Stack.

If you have run an API governance program, you already know it can fall apart. What surprises people is how predictably it fails the same way, regardless of company size or industry or how much budget went in. Someone stands up a governance team, writes the standards, buys the tooling, and convenes a review board. Six to eighteen months later the APIs are still inconsistent, developers are still doing their own thing, and nobody can answer the question that actually matters: what APIs do we have, and who owns them?

The program succeeded at documentation and never reached enforcement. I have watched that gap open at bank after bank, insurer after insurer, and it is what every governance post-mortem comes down to.

The failure pattern

The failure is quiet and it compounds. A review board is the usual reflex, and it works until the queue outgrows it. Past a few dozen teams the board becomes the bottleneck, developers under deadline pressure stop waiting and build their own versions, shadow APIs accumulate, and the documented standards drift from what is actually in production. The program eventually collapses or resets and starts over with the same holes underneath it. By the time anyone takes a real inventory, a decade of API debt is normal: contracts never written, owners long gone.

Talk to a team on its second or third attempt and you hear the same conclusion: the standards were never the problem, what was missing was anything that enforced them where specs get written. These teams already have the standards. What they are paying for now is enforcement that holds.

Three failure modes

1. Standards with nowhere to run

Standards live in a wiki, and nothing runs where the spec is authored. Violations pile up until a security review or an audit finds them, by which point they cost far more to fix than they would have at design time. The numbers I use come from McKinsey: a defect caught while the spec is being designed costs minutes, the same defect caught after CI costs four to eight times more, and in production it costs ten to a hundred times more. A naming-convention miss caught as the developer types is a two-minute correction. The same miss caught in a quarterly audit is a version bump and a migration plan.

I have watched this land as a board-level finding. At one financial services firm, a security audit turned up 43 undocumented APIs in production. Two had been built by an engineer who left eighteen months earlier. A third was still calling an authentication endpoint the security team had disabled the previous quarter. The finding was not really about the 43 APIs. It was that nobody in the room could answer the first question anyone asked: what do we have?

A lot of teams think moving Spectral into CI closes this gap, and it does not. CI runs after the design is locked and the developer has already written code against it, so the cheapest move left is to suppress the error. Run a linter only in CI and you teach suppression. The programs that hold run the same ruleset at authoring time, in the editor as the spec is written, and again in CI as the merge gate, so a violation shows up as design feedback while it is still cheap to act on. One global bank made a passing spec the condition for writing any code, with a target of pulling time-to-first-call from 100 days down to five. The point of the gate, in the API lead’s words, was “to prevent any code being written until the spec passes.”

2. Governance that lives outside the work

Governance that forces a context switch gets skipped. A tool in its own portal gets opened approximately never, and a review board with a week-long queue across hundreds of teams gets ignored by anyone on a deadline, which is everyone. Developers are not being difficult. Under a deadline they do whatever produces a working API fastest, and a governance step that adds a week is not it.

I have heard the same sentence, close to word for word, from developers at a national carrier and at more than one bank: they cannot get what they need fast enough, so they build their own version. One national carrier later measured the duplicates that behavior produced and found 99 percent overlap across specs teams had rebuilt because they could not find the canonical one. A payroll company I worked with surfaced 37 copies of the same employee-picker API for the same reason.

That is what happens when governance is designed as an audit function instead of part of how people build. And you cannot govern what you cannot see, which is why the programs that work get honest about the inventory first. The number is usually a shock. IBM puts the median enterprise at more than 15,000 APIs, and 78 percent of organizations cannot say exactly how many they have. One regional bank’s first real portfolio review turned up 295 ungoverned collections nobody knew were there. That number is useful precisely because it turns an abstract risk into a finite piece of work. Governance then runs on the same branches, in the same pull requests, through the same CI the team already uses, and when API specs get the same review as application code, there is nothing separate to avoid.

3. No plan for what agents generate

Coding agents now produce API specs at volume with no awareness of your naming conventions, error formats, auth schemes, or versioning rules. A spec can be valid OpenAPI and still break every standard you have defined. A review board that was already underwater at human speed does not function at agent speed.

The asymmetry is the part people miss. A developer who hits an inconsistent API reads the docs, asks in Slack, and works it out. An agent that hits the same inconsistency fails quietly, calls the wrong endpoint, or retries until it burns through a rate limit. I watched a large manufacturer’s AI initiative slip an entire quarter because its agents could not handle inconsistent error shapes that human developers had been quietly absorbing for years. The CFO wanted to know why nobody saw it coming.

This is no longer a far-off concern. Anthropic’s Model Context Protocol reached 97 million monthly SDK downloads by early 2026. The organizations spending heavily on AI are finding the governance prerequisite the hard way. One global insurer is funding its entire governance effort out of the AI infrastructure budget, because governance turned out to be the prerequisite to its AI roadmap. Another gates every new AI capability on its governance posture before it ships.

The programs that handle this do not build a second system for AI. They apply the same rules to an agent-authored spec that they apply to a human-authored one, because the merge gate does not care who or what wrote it. They also watch the right number. Rule coverage is a vanity metric; the one that matters is the ratio of suppressions to fixes. Forty rules at 10 percent adoption is a program failing quietly, whatever its coverage looks like on a slide, while twelve rules at 80 percent adoption is a foundation to build on. The threshold I watch is one suppression for every four fixes. Past that, something is wrong, and it is worth diagnosing before anyone adds another rule.

Why waiting gets more expensive

Only 10 percent of organizations have an API posture governance strategy, and 99 percent hit an API security issue in the past year (Salt Labs State of API Security, Q1 2025). Those two numbers describe the same gap from opposite ends.

Regulation has closed off the option of waiting. EU DORA has been directly applicable since January 2025 and covers roughly 22,000 financial entities, with penalties reaching 2 percent of global annual turnover. PCI-DSS 4.0 added 64 new requirements in March 2025. IBM’s 2025 Cost of a Data Breach report puts the average breach at $4.44 million.

Then there are the costs that never reach a dashboard: authors leave and ownership evaporates, violations get suppressed instead of fixed so the program looks healthier than it is, and ungoverned APIs become hard failures the moment agents start calling them at scale. Gartner estimates that API mismanagement runs enterprises up to $200,000 an hour in downtime. The governance debt that felt survivable last year is now blocking funded AI work.

The five-question test

A working governance program can answer five questions off a live dashboard, without commissioning a project to find out:

• How many APIs are in production, and is that number going up or down?
• Who owns each one, and when that owner leaves, does ownership transfer or vanish?
• Which APIs pass governance rules today, and are violations trending toward fixes or toward suppressions?
• Can a developer find an existing internal API in under five minutes?
• Are agents calling these APIs, and are those APIs in a state a machine can actually consume?

If pulling those answers still takes a project, the program is still documentation. The ones that answer in real time do it by running governance where the work already happens: in the editor as the spec is authored through Spec Hub, in CI as the merge gate through the Postman CLI, and in an API Catalog that carries ownership, conformance, test coverage, and production health as one live view instead of a quarterly compilation. Agent Mode runs the same rules against what the agents write, and that same governed catalog is what feeds the MCP server when those APIs get exposed to agents as tools. I have never seen a team clear this bar by writing more standards.

None of this is exotic. It is the difference between a program that decays and one that compounds, where each cycle sharpens the ruleset and the audit trail falls out of normal work instead of a fire drill. That is the program our API governance ebook walks through, from the first inventory to a catalog agents can actually consume. Download the ebook here.

The post Why API Governance Programs Break Down, and What the Successful Ones Do Differently appeared first on Postman Blog.