Originally posted in Obics.io I have been hearing of developers who run dozen agents in parallel and create 40 pull requests a day, but I never quite believed it myself. I was never able to do that because the mental overhead of multitasking was just too much for me. But in the last few weeks, I drastically changed the way I work as an experiment and I was able to do just that.

Originally posted in Obics.io So, you’re trying to understand why your DataDog metrics bill is so high and you can’t figure it out? You’re not alone. DataDog pricing is one of the great mysteries of the universe. But in this post, we’ll go over how it works and try to make it as clear as possible. The first part of the bill for infrastructure hosting is a fixed price per host.

The Trump phone was never a serious phone. Not when it was announced last June, in dodgy renders and with an incoherent spec sheet. Nor when Trump Mobile admitted - just two weeks later - that it wouldn't be made in the US. Not even when the company revealed the final phone, first to me over a video call in February and then to the world in April through a short commercial with the slick sheen of AI.

It's now on sale for $499, past the days of its tenuous, ever-shifting release dates. A few buyers even have the phone, The Verge among them, though more still seem not to.

It's clear now that the T1 is a real phone, but that doesn't mean it's …

Read the full story at The Verge.

Security is never finished. That conviction is where the Secure Future Initiative (SFI) started two years ago and continues to guide us today. AI is reshaping cybersecurity. Cyberattackers can discover vulnerabilities, chain attack paths, and scale exploitation faster than manual approaches allow. Defenders can use the same advances to identify risk, strengthen protections, and accelerate response. As the threat landscape evolves, security must evolve with it.

This latest SFI progress report shows how Microsoft is adapting to that reality: strengthening security foundations for an AI-accelerated cyberthreat landscape, applying AI to improve security outcomes at scale, and preparing for future challenges such as scalable quantum computing.

This report organizes our progress into three outcome-driven themes—secure foundations, proactive defense, and future-ready security—and shares lessons learned, practical guidance, and deeper insights across the culture, governance, principles, and engineering pillars that underpin security at Microsoft.

Secure foundations

The most consequential security failures rarely come from a single missing control. They come from environments where identity gaps, unmanaged assets, and inconsistent configurations sit side by side, creating composite attack paths that determined threat actors can chain together. SFI addresses this systemically, strengthening security across our environment. The results show the progress:

• Phishing-resistant multifactor authentication now protects 99.97% of user/device pairs at Microsoft.
• More than 732,000 resources have had public access revoked, with network isolation scaling across 1 million resources.
• 1.4 million unused apps were decommissioned and cross-boundary credential isolation reached 98.7%.
• Engineering defaults now prevent 83% of pipelines from accessing unapproved package endpoints.

These controls form reinforcing layers: identity feeds access governance, access governance feeds segmentation, segmentation contains blast radius, and engineering defaults reduce what enters production in the first place. One of the lessons we have learned is that foundations are durable only when they’re continuously validated, not periodically audited.

Proactive defense

Secure foundations reduce the attack surface. Proactive defense builds on that foundation to find and fix weaknesses quickly. Traditional practices like code review and penetration testing remain essential. The difference now is that frontier AI can discover vulnerabilities and chain exploit paths faster than manual review can keep up. That’s a threat and, when used well, an advantage. We’ve leaned into that advantage to find real risk earlier and close it before a cyberattacker can act.

• We built a multi-agent AI system that delivers proactive assessment of a cloud service’s source code, identity configurations, network topology, and runtime state to surface composite vulnerabilities that a single-layer review could not catch. More than 90% of findings confirmed by our security engineers, enabling proactive actions to improve security posture.
• This system builds on other tools in our security portfolio—such as the Microsoft Security multi-model agentic scanning system (codename MDASH), which scans source code to identify, validate, and prioritize vulnerabilities at scale—and adds configuration, identity, network, and runtime context to comprehensively assess the service.
• More than 100 new detections were added this year (more than 350 total), shifting from signature-based to behavior- and baseline-driven detection.
• More than 550,000 critical and high-risk open-source vulnerabilities were remediated, with about 3 million container vulnerabilities patched per month through automation.

Future-ready security

Some risks have not fully arrived yet, but waiting for them is not an option. The most urgent example is the transition to post-quantum cryptography. The threat is already here in the form of “harvest now, decrypt later”: data encrypted today could be captured and decrypted once quantum capability matures.

• We are accelerating the Microsoft Quantum Safe Program (QSP) timeline, with the goal of transitioning to post-quantum cryptography (PQC) in critical products and services by 2029.          
• PQC is now an SFI-measured engineering requirement, with workstreams advancing across network traffic, data-at-rest protection, and trust chain modernization.
• Quantum-safe algorithms (ML-KEM, ML-DSA) are available today across major platforms.
• Read more in the recent blog: Accelerating quantum-safe readiness.

Governance, culture, and principles

Foundational progress like this is only possible because of the people committed to making it possible. Security is a core responsibility for every employee at Microsoft: mandatory Trust Code training was completed by more than 99% of full-time employees. Governance is what makes it scale, with accountability driven through our Deputy Chief Information Security Officer (CISO) structure and a centralized risk register. And our principles—secure by design, secure by default, secure in operations—are what turn intent into product, like Microsoft 365 Baseline Security Mode. Tools alone don’t create durable security; culture, accountability, and secure defaults do.

What you can do today

Throughout the report, we share actionable guidance for organizations at any stage of their security journey. A few starting points:

• Enforce phishing-resistant multifactor authentication and eliminate legacy authentication protocols.
• Inventory every tenant and classify it. Apply secure-by-default provisioning with drift detection.
• Evaluate how identity, code, configuration, and network relationships interact in production. Prioritize composite attack paths over isolated findings.
• Inventory your cryptographic dependencies now and establish transition plans for post-quantum readiness.
• Enable Baseline Security Mode in Microsoft 365 for secure-by-default configuration at no additional cost.

Read the full SFI report, including detailed pillar-level progress and additional customer guidance.

Each hardening action changes the cyberattacker’s approach. The compounding effect of SFI is that attackers face a shrinking set of viable paths, while defenders gain better telemetry, stronger defaults, and sharper prioritization for the paths that remain.

Security is a team sport. We are grateful for the partnership of our customers, security researchers, and the broader industry as we work together to make the world a safer place for all.

Learn more

• Defending the cloud at AI speed.
• Beyond the benchmark: Advancing security at AI speed.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Securing our future: July 2026 progress report on Microsoft’s Secure Future Initiative appeared first on Microsoft Security Blog.

This week data and AI evangelist Christina Stathopoulos returned for a solo news briefing. Instead of exploring one or two topics in depth, Christina sorted the week’s headlines into a handful of threads: advances in physical hardware to keep up with AI demand, the widening reach of government oversight into frontier model companies, and a workforce that’s reorganizing faster than job titles can describe it.

Along the way, Christina flagged a few interesting items too small to garner their own sections. Anthropic launched Claude Science, a workbench that pulls research databases, lab tools, and compute into one place for life sciences researchers, following OpenAI’s earlier release of GPT-Rosalind, a model tuned for biological reasoning. And OpenAI began a limited preview of its GPT-5.6 family, three models (Sol, Terra, and Luna) built for different jobs instead of one model trying to do everything. Watch now.

The AI hardware race has moved from parameters to atoms and watts

The biggest model headlines get the attention, but the real story this week was what they’re running on. IBM introduced the world’s first sub-1 nanometer chip technology, measuring 0.7 nanometers, or roughly a third the width of a strand of DNA. We’re approaching the limits of how small we can shrink transistors, Christina pointed out, so IBM is now also stacking them vertically. With 0.7 nm transistors, the company can pack around 100 billion into a fingernail-sized chip that claims to have 50% higher performance and 70% lower power consumption than the previous 2 nanometer generation. They’re not yet a product in the wild, but sub-1 nanometer chips are a marked research breakthrough in the angstrom era.

OpenAI and Broadcom have taken a different approach. Last week, they unveiled Jalapeño, a chip built specifically for LLM inference rather than training. As Christina put it, training gets the headlines, but inference is where AI actually reaches people. Every improvement in cost, speed, and reliability means a faster answer or a cheaper product for the people using it every day, and a small efficiency gain multiplied across hundreds of millions of users adds up fast. That’s why frontier labs are moving away from off-the-shelf tech to designing their own.

NVIDIA, meanwhile, shared a new closed-loop, fully liquid-cooled AI factory design that uses coolant that can run as warm as 45°C (113°F), removing the dependence on chilled water that’s made data centers a target for criticism over their energy and water use. Together, these three stories point to physical infrastructure, not algorithms, as AI’s next real opportunity.

Government oversight is turning into a permanent fixture

Anthropic restored public access to Claude Fable 5 and Claude Mythos 5 after the US government lifted the export controls that had pulled the models offline for security concerns tied to vulnerability discovery. The company added a new cybersecurity classifier meant to block known jailbreak techniques and says it will keep working with the government on AI security matters. It’s a reminder that access to frontier models can be switched off, and that the terms for turning it back on are now being negotiated case by case. Epoch AI data shows critical vulnerability disclosures had already spiked to 3.5 times the previous monthly peak right after Anthropic’s Mythos preview went live. We’ve mentioned before that this cuts both ways: Attackers can use AI to find weak points faster, but so can the defenders trying to patch them first.

OpenAI’s GPT-5.6 family launched as a limited, tiered preview for trusted partners at the government’s request, with broader access to follow. At the same time, the Financial Times has reported that OpenAI is proposing to give the US government a 5% equity stake in the company, which it’s pitching as a way to ensure that some of AI’s economic upside would flow back to taxpayers. It’s also, as Christina noted, likely an attempt to build public trust. Whether or not that stake materializes, government involvement in frontier AI now looks like a standing condition that companies build around, and it raises real questions for anyone outside the US who doesn’t control the terms of their own access to these models.

Roles are evolving faster than the org chart can describe

The best model in the world can’t close the gap between what a client wants and what actually gets built. For that, organizations are increasingly betting on the role of forward-deployed engineer, a mix of platform engineer, solutions architect, and product manager, who embed directly with clients to turn AI ambitions into working systems. Microsoft committed $2.5 billion and AWS committed $1 billion to new AI deployment units, following similar moves earlier this year from OpenAI and a ServiceNow-Accenture partnership. (Maya Mikhailov and Doug Shannon had some thoughts about the limits of this approach back in June.)

Boris Cherny, the creator of Claude Code, has been thinking beyond job titles to the function each team member performs according to their particular strengths and interests. Looking at his own team, he identified five archetypes: the prototyper, who generates ideas most of which won’t ship; the builder, who turns an idea into a production-grade product; the sweeper, who simplifies code and improves performance; the grower, who iterates on a shipped product to improve market fit; and the maintainer, who keeps a mature system secure, reliable, and fast at scale. People can span two or three of these archetypes at once, and none of them maps cleanly to “engineer” or “designer.”

Organizations on the path to becoming AI-native have to rebuild from within, and they have to do it quickly. Christina shared examples of two very different approaches they’re taking to get there. SAP, facing a stock slide, is cutting costs to double down on hiring AI talent externally, while IKEA is retraining its existing employees for AI-enabled roles instead. We’ll see more companies considering their options, but as Tim O’Reilly recently noted, no matter which path they take, successful companies will be ones that intentionally build a skill infrastructure that incentivizes knowledge sharing as teams figure out the best ways to use this technology for their specific circumstances.

What’s next

Christina closed the show with a story not about building products or raising funding rounds but about using AI to protect people. Google’s Android earthquake alert system warned an estimated 11.4 million people ahead of recent earthquakes in Venezuela, using accelerometers already built into their phones to detect seismic waves and send warnings with just seconds of lead time. The company is using the same underlying approach, pairing sensor and satellite data with AI, to map wildfire boundaries in near real time through Google Maps and Search and to forecast floods up to seven days out. It’s an encouraging counterweight to the stream of product releases and security incidents we usually cover.

Christina will host This Week in AI throughout July. Next week, she’ll cover the growing battle over AI chips as DeepSeek, Anthropic, and Samsung make major moves, explore the rise of agentic ransomware, and examine why AI-generated code is outpacing our ability to review it, plus the release of OpenAI’s much-awaited GPT-5.6 and some fascinating new research from Anthropic. If you’re an O’Reilly member, join us live. If not, try it out with a free trial or check out our takeaways here on Radar each Friday and watch full episodes on YouTube, Spotify, Apple, or wherever you get your podcasts.

If you’re looking for a more technical deep dive, on July 23 Christina will host the AI Superstream focused on AI harnesses. Join in to discover how our lineup of experts are building and running reliable, production-ready autonomous agent systems. Register here.

If you’ve worked on a team long enough, you’ve probably had the conversation. Someone shares a Postman collection, another developer imports it, and somewhere in that collection there’s a hardcoded API key. Or a Bearer token. Or a database password sitting in plain text inside an environment file that got checked into version control three months ago.

It’s one of those problems where everyone knows it’s bad practice, but the tooling hasn’t made doing the right thing easy enough. Until now.

We’ve shipped three new capabilities that handle secrets detection and storage automatically: Local Secrets Protection, Postman Shared Vault, and Secrets Resolution. Together, they catch secrets at runtime, secure them in a vault based on your team’s policy, and replace the raw values with variable references in your collections and environments. Available across all plans, including the free plan.

The problem worth understanding

Before getting into what shipped, it helps to be specific about why secrets leak in the first place.

Postman collections and environments are designed to be shared. That’s the point. You build a collection, add request examples, configure an environment with your API’s base URL and auth headers, and share it with your team so they don’t have to set everything up from scratch.

The issue is that environment variable values travel with the collection. If you put your actual API key in an environment variable’s “current value” field and then export that environment to share it, the key goes with it. If you store credentials in collection-level variables, same thing. If you use a pre-request script that hard codes a token because you were debugging something quickly last Tuesday and forgot to clean it up, that token is now in your team workspace.

According to GitGuardian’s State of Secrets Sprawl report, millions of secrets are exposed in public repositories every year, and internal tools and collaboration platforms are a growing vector. API clients are exactly the kind of tool where developers store credentials and then share artifacts without thinking twice.

The traditional mitigation is discipline: use variable references, never put real values in “initial value” fields, rotate credentials regularly, do periodic audits of your workspaces. Useful advice, but it depends on every developer getting it right every time.

What we shipped

The three new capabilities work together as a system:

Local Secrets Protection runs on your machine. When Postman detects what looks like a secret in a request, a pre-request script, an environment value, or anywhere else in your workspace, it intercepts it before it syncs to the cloud or propagates to a shared collection. The detection happens at runtime, so you don’t have to remember to scan manually.

Postman Shared Vault is the team-facing piece. It’s a centralized vault that workspace administrators manage. Admins configure which types of secrets get stored there, set the scope (which workspaces or teams can access it), and control the policy for how secrets are stored and rotated. Developers access vault-stored secrets through variable references without ever seeing the raw values.

Secrets Resolution ties the two together. When a secret is detected and secured, Postman replaces the raw value with a variable reference automatically. Your collection ends up with {{api_key}} where a real key used to be. Your environments stay clean. And anyone who later imports or accesses that collection gets the variable reference, not the credential.

How Local Secrets Protection works

When you make a request or run a collection, Postman scans the request context for patterns that look like secrets. This includes common formats: API keys, Bearer tokens, OAuth tokens, private keys, connection strings. The detection runs on your local machine before anything syncs.

If a secret is detected, Postman applies the vault policy your administrator configured:

• Store locally: The secret is secured in Postman Local Vault on your machine. It never syncs to the cloud. Other developers on your team can’t access it, which is appropriate for credentials that are specific to you (your personal developer API key, for example).
• Store in Shared Vault: The secret is pushed to Postman Shared Vault and becomes accessible to other team members who have permission, through the vault’s access controls.

The policy is set by a workspace admin, so individual developers don’t have to make judgment calls about where a secret should live. You get a notification when a secret is detected and secured.

For developers, the day-to-day experience changes in one useful way: you can drop a real API key into an environment variable to get something working, and Postman handles moving it to the vault. You don’t have to remember the cleanup step.

Postman Shared Vault for teams

The Shared Vault is the piece that matters most at the team level. Without it, secrets management in Postman worked more or less like it works everywhere else: tell developers not to commit credentials, remind them periodically, notice the leak after the fact.

Shared Vault gives admins actual controls:

• Define which secret types are vaulted: You can configure detection patterns and policies per secret type. API keys might go to the Shared Vault; personal OAuth tokens might stay local.
• Scope access: Control which teams, workspaces, or users can read from the vault.
• Rotate credentials once: When an API key needs to be rotated, you update it in the Shared Vault and the change propagates to everyone who’s using the variable reference. No more asking every developer to update their local environment.

For teams that already integrate with external secret managers, Postman also supports Postman Vault Integrations with 1Password, AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault. The Shared Vault and external integrations can coexist, so you’re not forced to migrate everything.

Secrets Resolution: variable references without the manual work

Secrets Resolution is the part that makes the other two capabilities actually usable in practice.

After a secret is detected and secured, Postman replaces the raw value in your collection or environment with a variable reference. The collection is updated in place. If you were using a literal API key in a request header like this:

GET https://api.example.com/v1/users
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

After Secrets Resolution runs, it becomes:

GET https://api.example.com/v1/users
Authorization: Bearer {{api_token}}

The variable api_token is now backed by your Local Vault or Shared Vault. When the request runs, Postman resolves the variable from the vault. The resolved value never appears in logs or collection exports.

This is meaningful for collections you’re writing from scratch, but it’s especially useful for collections that have been around a while. Teams often let hardcoded values accumulate in shared collections over months without noticing. Running Secrets Resolution over an existing workspace can surface problems you didn’t know you had.

Working with vault-backed variables in scripts

Vault-backed variables work like any other Postman variable in your test scripts and pre-request scripts. You reference them with {{variable_name}} syntax, and Postman resolves the value at runtime.

A test script that validates an authenticated response looks the same regardless of where the token lives:

pm.test("Request authenticated successfully", function () {
    pm.response.to.have.status(200);
});

pm.test("Response includes user data", function () {
    const response = pm.response.json();
    pm.expect(response).to.have.property("id");
    pm.expect(response).to.have.property("email");
});

Where it matters is in pre-request scripts that dynamically refresh tokens. Instead of storing a refresh token in a plain environment variable, you can store it in the vault and reference it:

const refreshToken = pm.vault.get("refresh_token");

pm.sendRequest({
    url: "https://auth.example.com/oauth/token",
    method: "POST",
    header: { "Content-Type": "application/x-www-form-urlencoded" },
    body: {
        mode: "urlencoded",
        urlencoded: [
            { key: "grant_type", value: "refresh_token" },
            { key: "refresh_token", value: refreshToken },
            { key: "client_id", value: pm.environment.get("client_id") }
        ]
    }
}, function (err, response) {
    if (!err && response.status === 200) {
        const newToken = response.json().access_token;
        pm.vault.set("access_token", newToken);
    }
});

The pm.vault API lets scripts read from and write to the vault programmatically. Tokens that get refreshed during a collection run stay in the vault rather than being written back to a plain environment variable.

For more on Postman scripting, the Postman Docs pre-request scripts reference covers the full API surface.

Admin setup: configuring vault policy

Workspace admins configure vault policy in the admin settings. The main decisions are:

1. Detection scope: Which workspaces have Local Secrets Protection turned on
2. Default vault target: Where detected secrets go by default (Local Vault or Shared Vault)
3. Secret type policies: Whether specific secret types (API keys, OAuth tokens, connection strings) have different routing rules
4. Shared Vault access: Which teams or workspaces can access vault-stored secrets and at what permission level

Policy changes apply to new detections going forward. Secrets already in your collections and environments are migrated through Secrets Resolution, which you can run manually or configure to run automatically.

If you’re managing a larger team and want to integrate with an external secret manager rather than Postman Shared Vault, the Postman Vault Integrations documentation walks through the connector setup for AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and 1Password.

Things to watch for

Existing collections aren’t automatically migrated. Local Secrets Protection and Secrets Resolution apply to secrets as they’re encountered going forward. If you have collections with hardcoded values that haven’t been touched recently, you’ll want to run Secrets Resolution explicitly over those workspaces. Don’t assume that turning on the feature retroactively cleans up your workspace.

Initial value vs. current value still matters. Postman has always distinguished between a variable’s “initial value” (shared with your team) and “current value” (local to your machine). Secrets Resolution handles detection, but understanding this distinction is still useful for cases where vault detection doesn’t catch something. See Postman Docs on managing environments for a refresher.

The pm.vault API is available in scripts. If you’re programmatically managing tokens in pre-request scripts, you can switch from pm.environment.set() to pm.vault.set() for anything that’s a credential. The vault-backed value won’t appear in the Postman Console output, which matters if you’re running collections in CI and logging output.

Plan availability covers everyone. Local Secrets Protection, Postman Shared Vault, and Secrets Resolution are available on all plans, including the free plan. The Shared Vault capacity and admin policy controls scale with plan tier, but the core detection and variable reference replacement works across the board.

Trying it yourself

The best way to see this in action is to take an existing collection that has hardcoded credentials and watch what happens when Local Secrets Protection runs.

1. Open a collection in Postman that includes a request with a real API key in an environment variable’s current value.
2. Run the request. If Local Secrets Protection detects it, you’ll see a notification and the value will be moved to your vault.
3. Check the environment variable afterward. The current value field will now reference the vault-backed variable.

For team scenarios, have your workspace admin set up a Shared Vault policy, then try sharing a collection with a vault-backed variable with a colleague. They’ll get the variable reference and pull the value from the Shared Vault at runtime, without ever seeing the credential itself.

The Postman Vault documentation has the full setup guide including the admin configuration walkthrough.

Resources

• Postman vault offerings documentation — covers Local Vault, Shared Vault, and Vault Integrations
• Postman Secret Scanner — related feature that scans published collections and APIs for exposed secrets
• Managing environments in Postman — initial value vs. current value explained
• Pre-request scripts reference — pm.vault API and scripting documentation
• GitGuardian State of Secrets Sprawl — research on secrets exposure across developer tooling
• OWASP API Security Top 10 — broader context on API security risks including broken authentication

The post What’s new in Postman: Secrets management built in appeared first on Postman Blog.