How many tabs do you have open alongside your pull request?

Imagine picking up a new issue in your product’s free-trial onboarding flow: make the “invite your teammates” step optional. Support keeps flagging the step as a friction point as signups increase. Quick win, right?

From scoping to deployment, you need answers to these four questions:

• Is this even the right change?
• Are the dependencies I’m touching clean?
• How do I roll it out safely?
• Is it safe to deploy right now?

Each answer lives in a different tool, so working through the pull request means carrying the same context across four places.

GitHub agent apps bring the tools you need to answer those questions to where you’re already working, powered by the same platform and harness as our own Copilot cloud agent. The illustrative walkthrough below shows how you can use services you already depend on, such as Amplitude, Endor Labs, LaunchDarkly, and PagerDuty to answer these questions and complete this request, without ever leaving GitHub.

1. Before you build it

Support says the “invite your teammates” step is annoying for customers who are onboarding with your product, but they haven’t given an indication of who has complained or whether those complaints lead to churn. You’d be right to be skeptical. So instead of opening Amplitude and building a query to confirm your hunch, you ask the Amplitude agent right from the Agents tab:

@amplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments we're measuring. 

The split comes back clear: team users who finish the step are more likely to retain later, while solo users don’t have that correlation. A rescope is now justified: defer the step for solo signups and keep it for teams.

Access to product insights is now within GitHub, enabling course correction before any code is written.

2. As you build it

Copilot opens a draft pull request for the change. The implementation also updates dependencies used by the onboarding flow. Instead of waiting for a CI scan to fail later, you ask the Endor Labs agent in a comment:

@endor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?

The agent identifies the changed dependencies, checks them for known vulnerabilities and broader package risk, then reports back in the pull request. This time, everything looks clean. Nothing to remediate.

Dependency review becomes a proactive check while the change is still in front of you. Much better than remediating a CI scan after it fails.

3. Rolling it out

The previous finding now gets carried through to implementation: solo signups get the optional path, while teams keep the existing one. Because these segments are set at signup, a feature flag can target them directly. Ask the LaunchDarkly agent to set it up for you, the same way you’d ask a team member:

@launchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. 
   - key: defer-team-invite 
   - type: boolean 
   - default: false 
   - target: solo-intent signups 
   - rollout: internal > 5% > 25% > 100% 

The agent creates the flag in LaunchDarkly and adds the code implementation as a commit you review. If the target environment requires approval, it creates an approval request instead of applying the targeting change directly. A human still decides whether the rollout moves forward.

Flag setup goes from a second tool, a manual code handoff, and Slack coordination to one pull request comment and a commit you review.

4. Before you ship

Review tells you the code is correct, but whether the service is in a good state for a deployment is a different question. Before merging, you ask the PagerDuty agent:

@pagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed. 

The agent maps the repository to its PagerDuty service, checks for active incidents, reviews the previous 90 days, and compares the files in the pull request with areas involved in past incidents.

This time, the risk is low. There are no active incidents and no meaningful correlation with the current changes. The recommendation is to proceed.

Nothing dramatic happens, but that’s the point. Checking deploy risk becomes a routine step for your pull requests instead of something you do only when a release already feels dangerous.

What changes

You still use Amplitude, LaunchDarkly, Endor Labs, and PagerDuty. But now, you no longer need to carry the context between them, and they’ll all work directly in your GitHub workflows.

As work moves from idea to production, developers can bring each service into GitHub when its context or capabilities matter. With agent apps, GitHub becomes the place where developers and agents coordinate what happens next, without developers switching contexts.

Try it

Agent apps are available from the GitHub Marketplace. Install one, enable it for your organization, and take it for a spin:

• Assign it to an issue to kick off a task.
• @mention it in a pull request comment for analysis or action.
• Select it from the Agents tab in your repository.

Your tools are still your tools. Now, they show up where you are already working: on GitHub. Explore the other inaugural agent apps and start bringing your stack directly into your workflow:

• Packfiles’s agent reads your backlog and builds a migration strategy. reads your backlog and builds a migration strategy.
• Miro‘s agent connects visual collaboration with code workflows.
• Bright Security‘s agent autonomously handles end-to-end dynamic security testing inside GitHub.
• SonarQube‘s agent brings analysis, quality gates, and remediation into GitHub agent sessions.
• Octopus Deploy‘s agent can identify, diagnose, and resolve deployment failures.

The post How to bring your software delivery workflow into GitHub with agent apps appeared first on The GitHub Blog.

AI agents are multiplying, and many of the systems used to manage them weren’t designed for their scale or speed. This week, host Vicki Reyzelman, a senior solutions engineer at Akamai, used one figure to connect developments in cybersecurity, infrastructure, education, and AI governance: For every human on the internet, there are 144 agents.

That ratio framed a larger question running through the episode. What changes when software can operate continuously, respond in seconds, and increasingly take action without waiting for a person? Vicki looked at faster cyberattacks, growing investment in agent security, the resource demands of AI infrastructure, and the expansion of AI from chat interfaces into robotics. The episode points beyond model selection to the systems required to deploy AI safely and reliably.

Security operations have to match agent speed

AI is compressing the time required to find and exploit software weaknesses. Vicki pointed to reports of attackers moving in minutes and vulnerabilities being exploited soon after public disclosure. She also described an attack against one of her customers in which the attacker returned, changed tactics, and tried again.

Traditional security processes assume there is time for people to investigate an alert, understand the vulnerability, deploy a patch, and monitor the result. That assumption gets weaker as automated systems become faster at reconnaissance and adaptation. Vicki argued for multiple defensive layers across APIs, applications, and networks so that one missed signal does not become a single point of failure.

We’ve followed agent security throughout This Week in AI, and the discussion now centers on how enterprise security changes around more autonomous software. That puts more weight on automated defenses, tighter permissions, and monitoring systems that can constrain machine activity at comparable speed.

AI capacity depends on physical infrastructure

AI capacity requires electricity, cooling, water, data center space, and the infrastructure that supplies them. Vicki connected large hyperscaler investments with projections for sharply higher data center energy and water use by 2030. An audience member added a useful example from a university data center that can reuse waste heat during colder months but has to shed that heat during warmer weather.

Those constraints affect deployment decisions directly. Organizations have to account for power availability, cooling systems, water access, latency, security, and local infrastructure capacity alongside model performance and cost.

Government policy already shapes those choices. The episode paired expanding investment in AI infrastructure with growing regulatory requirements in Europe. AI infrastructure now spans engineering, economics, compliance, and public policy, which means deployment decisions increasingly involve several systems at once.

Human judgment becomes more valuable when AI can act

Rapid AI adoption increases the value of foundational knowledge. Vicki raised that issue while discussing AI use in education and research. Students may have easier access to explanations and answers, but someone who does not understand the subject may have little basis for recognizing an incorrect result. The same problem appears in scientific work, where reliable AI output still depends on reliable data and reproducible processes.

That evaluation problem becomes more consequential when AI controls physical systems. Vicki described systems that can perceive their surroundings, pass information about that environment to a model, and use the result to guide physical actions. Errors in those systems can extend beyond a bad answer on a screen.

Practitioners still need to evaluate evidence, recognize weak assumptions, and decide where automated action should stop. Better models can reduce some forms of manual work, but they also increase the value of people who understand the domain well enough to know when a system’s output does not fit the situation.

What’s next

AI systems can now operate faster and more independently than many of the processes surrounding them. Security teams have to defend at machine speed. Infrastructure planners have to account for physical resource limits. Researchers, students, and practitioners have to evaluate increasingly capable systems without assuming that capability guarantees correctness.

The 144-to-one ratio makes that change concrete. Agent adoption is already testing whether organizations can govern these systems, support the infrastructure they require, and preserve informed human oversight.

Join us again next Monday for another episode of This Week in AI, when we’ll dive into more of the news, issues, and key developments shaping the AI era. And check back each Friday for the latest episode, or watch on YouTube, Spotify, Apple, or wherever you get your podcasts.

Authentication has changed dramatically over the past decade. Not long ago, attackers focused primarily on stealing usernames and passwords because that was all they needed to gain access to an environment. As organizations adopted Multi-Factor Authentication (MFA), Conditional Access, passwordless authentication, and stronger identity controls, compromising an account became significantly more difficult. Microsoft 365 and Microsoft Entra ID have played a major role in driving that improvement, making traditional password-based attacks far less successful than they once were.

Unfortunately, attackers adapted just as quickly.

Rather than attempting to defeat authentication itself, many threat actors now focus on what happens after authentication has already succeeded. Once a user has entered their password, completed Multi-Factor Authentication, and successfully signed into Microsoft 365, Microsoft Entra ID issues a series of tokens that allow the user to continue working without repeatedly authenticating. Those tokens become the new target. If an attacker can steal and replay them before they expire or are revoked, they can often gain access to Microsoft 365 services without ever knowing the user’s password or triggering another MFA challenge.

This represents an important shift in how we think about identity security. MFA remains one of the most effective security controls available and should continue to be deployed everywhere possible. The issue is not that MFA is broken. The issue is that authentication is only one stage of the overall identity lifecycle. Once a user has successfully authenticated, the authenticated session itself becomes an asset that attackers actively target.

For organizations built around Microsoft 365, this has significant implications. Administrative tasks are increasingly performed through cloud services such as Exchange Online, Microsoft Entra ID, SharePoint Online, Microsoft Teams, Microsoft Graph, and Azure. Almost every one of these services exposes extensive management capabilities through PowerShell. If an attacker successfully compromises an authenticated administrative session, PowerShell quickly becomes one of the most valuable tools available for expanding access, maintaining persistence, and performing administrative actions across the environment.

Understanding how these attacks work is therefore only half of the challenge. The other half is reducing what an attacker can actually do after authentication has already been compromised.

Authentication Doesn’t End With MFA

When a user signs into Microsoft 365, the authentication process involves considerably more than simply validating a username and password. Microsoft Entra ID evaluates the user’s credentials, applies Conditional Access policies, verifies device compliance where required, and prompts for Multi-Factor Authentication if the organization’s policies require it. Once those requirements have been satisfied, Microsoft issues a collection of authentication tokens that allow the user to continue interacting with Microsoft 365 services without repeatedly signing in.

These tokens exist for a very practical reason. Imagine having to complete Multi-Factor Authentication every time Outlook refreshed your mailbox, every time Teams loaded a conversation, or every time SharePoint retrieved a document. Modern cloud services rely on authentication tokens to provide a seamless user experience while maintaining security behind the scenes.

The important point is that these tokens represent proof that the authentication process has already taken place. Microsoft no longer needs to challenge the user because the token itself demonstrates that the required authentication requirements were previously satisfied. As long as that token remains valid, Microsoft trusts the authenticated session.

From a usability perspective, this works extremely well.

From a security perspective, however, those tokens become highly valuable. Rather than attempting to defeat Microsoft’s authentication process, attackers simply attempt to steal the evidence that authentication has already occurred.

Understanding Session Token Theft

Session token theft is often misunderstood because it is frequently described as “bypassing MFA.” In reality, Multi-Factor Authentication has usually worked exactly as designed. The user authenticated successfully, completed the required MFA challenge, and Microsoft correctly issued an authenticated session.

The attacker simply steals that session.

The process itself is surprisingly straightforward. A compromised endpoint, malicious browser extension, information-stealing malware, or Adversary-in-the-Middle phishing attack captures the browser cookies or authentication tokens associated with the user’s Microsoft 365 session. Those tokens are then imported into another browser under the attacker’s control. When that browser connects to Microsoft 365, the existing authentication token is presented to Microsoft Entra ID, which recognizes it as a valid session and allows access without requiring another sign-in.

• No password is entered.
• No Multi-Factor Authentication prompt appears.
• No authentication challenge occurs because Microsoft believes the user has already completed that process.

This distinction is important because it fundamentally changes the security boundary. Organizations often spend considerable effort protecting usernames, passwords, and MFA methods, yet the authenticated session itself may receive far less attention. Once authentication has completed successfully, the session effectively becomes the new credential.

Why Browser Cookies Have Become So Valuable

Modern browsers are designed to improve the user experience by securely storing authentication information that allows users to remain signed in across multiple Microsoft services. As users move between Outlook, SharePoint, Teams, OneDrive, Exchange Online, and countless other cloud applications, those cookies allow Microsoft to recognize the authenticated session without repeatedly prompting for credentials. Attackers understand this extremely well.

Modern information-stealing malware rarely focuses exclusively on passwords anymore. Instead, many malware families specifically target browser profiles because they contain everything needed to recreate a user’s online identity. Session cookies, authentication tokens, browser profiles, saved credentials, autofill information, and cached authentication artifacts all become valuable because together they allow an attacker to rebuild an authenticated browsing session.

This is one of the reasons endpoint security has become such a critical part of identity protection.

Organizations often focus heavily on Microsoft Entra ID, Conditional Access, and identity governance while overlooking the fact that an infected endpoint may already contain everything an attacker needs to access cloud services.

Protecting the identity provider alone is no longer sufficient if the authenticated session can simply be copied from the user’s device.

The Evolution of Modern Attacks

Early attacks typically relied on malware installed directly on the endpoint to extract browser cookies after the user had already authenticated. While this technique continues to be used, more sophisticated attacks have evolved considerably. One of the most significant developments has been the rise of Adversary-in-the-Middle (AiTM) phishing frameworks such as Evilginx. Rather than stealing browser cookies from an infected endpoint, these attacks intercept the authentication process itself.

The victim receives what appears to be a legitimate Microsoft 365 sign-in page. Behind the scenes, however, the attacker is proxying the entire authentication session between the victim and Microsoft. The user enters their credentials, successfully completes Multi-Factor Authentication, and is redirected into the genuine Microsoft application. From their perspective, everything appears completely normal. The attacker, however, captures the authenticated session token immediately after Microsoft issues it.

Unlike traditional phishing attacks that attempt to steal passwords, AiTM attacks capture the authenticated session itself. The attacker never needs to know the user’s password again because they already possess proof that the authentication process has completed successfully.

This explains why organizations are increasingly investing in phishing-resistant authentication technologies such as FIDO2 security keys and passkeys. These approaches significantly reduce the effectiveness of credential interception attacks because the authentication process becomes cryptographically bound to the legitimate Microsoft domain rather than simply validating credentials that can be replayed elsewhere.

Why PowerShell Becomes the Next Target

Successfully stealing a Microsoft 365 session is rarely the attacker’s end goal. Access to email, documents, and collaboration platforms certainly provides valuable intelligence, but most attackers are ultimately looking for something far more powerful. They want administrative access that allows them to expand their control, establish persistence, manipulate the environment, or move laterally into additional systems.

For organizations built around Microsoft technologies, PowerShell often becomes the tool that enables those objectives.

PowerShell has become the management interface for almost every major Microsoft platform. Administrators use it daily to manage Exchange Online, Microsoft Entra ID, Microsoft Teams, SharePoint Online, Microsoft Graph, Azure, Windows Server, Active Directory, and countless third-party products. It provides consistency, automation, and scalability that simply cannot be achieved through graphical administration tools alone.

Those same advantages also make PowerShell extremely attractive to attackers.

Unlike traditional malware, PowerShell is already trusted by the operating system. It does not require an attacker to install additional software, exploit vulnerabilities, or bypass application control in many environments. If an attacker has obtained a legitimate administrative session, they can often use the same management tools as the administrator they have compromised. This is one of the reasons PowerShell is frequently associated with “living off the land” attacks, where adversaries deliberately use legitimate administrative tools to avoid detection.

Consider what a compromised Microsoft 365 Global Administrator account could potentially access through PowerShell. Depending on the organization’s configuration, that account may be capable of reading Exchange Online mailboxes, modifying Microsoft Entra ID users and groups, assigning administrative roles, creating application registrations, changing Conditional Access policies, modifying SharePoint Online permissions, interacting with Microsoft Graph, or automating administrative tasks across the tenant. None of these activities require malicious software. They simply require authenticated administrative access.

This is where traditional authentication controls begin to reach their limits. Once the attacker has successfully authenticated using a stolen session token, Microsoft 365 has already established their identity. From that point forward, the focus shifts away from authentication and towards authorization.

Authentication Does Not Equal Authorization

One of the most common misconceptions in enterprise security is that successfully authenticating a user automatically means they should have unrestricted access to everything their account can perform. In reality, authentication and authorization solve two very different problems.

• Authentication answers a relatively simple question: Who is this user?
• Authorization answers a much more important question: What should this user actually be allowed to do?

This distinction becomes particularly important when dealing with privileged administrative accounts. Many organizations still assign broad administrative permissions to users because it simplifies administration. An Exchange administrator may receive Exchange Administrator rights across the tenant. A SharePoint administrator may receive unrestricted access to SharePoint Online. A helpdesk technician may receive permissions that extend well beyond the tasks they perform on a daily basis. Under normal circumstances, those permissions are exercised responsibly by trusted administrators. During a session hijacking attack, however, the attacker inherits exactly the same capabilities.

From the attacker’s perspective, the compromised account is simply another administrative tool. If the account can execute PowerShell commands, assign permissions, create application registrations, or retrieve sensitive data, then those capabilities become available to the attacker as well.

The challenge therefore becomes limiting what an authenticated administrative session can actually accomplish after authentication has already succeeded.

Why Traditional Administrative Models Create Risk

Historically, privileged administration has often been built around standing administrative permissions. An administrator is assigned a privileged role and retains that level of access until the role is removed. Whenever they open PowerShell or connect to an administrative service, they immediately receive the full capabilities associated with that account.

While this approach is straightforward, it also creates a significant attack surface.

If the administrative account becomes compromised through phishing, session token theft, malware, or another identity attack, the attacker immediately inherits every permission associated with that account. There is no distinction between routine administrative work and high-risk privileged operations because the account always possesses both. Modern identity security has increasingly moved away from this approach.

Technologies such as Privileged Identity Management (PIM), Just-In-Time administration (JIT), and Conditional Access all attempt to reduce standing privilege by ensuring administrative access is only available when genuinely required.

PowerShell Just Enough Administration (JEA) takes that same philosophy one step further.

Instead of simply controlling who can access an administrative session, JEA controls what can actually be executed once that session has been established.

Defense-in-Depth Assumes Compromise

One of the most important principles in modern cybersecurity is that no single security control should ever be trusted to stop every attack. Organizations deploy Multi-Factor Authentication because passwords alone are insufficient.

• They implement Conditional Access because MFA alone is insufficient.
• They secure endpoints because identity controls alone are insufficient.
• The same principle applies to administrative access.

PowerShell Just Enough Administration should not be viewed as a replacement for strong authentication, phishing-resistant credentials, Conditional Access, or endpoint protection. Instead, it becomes another layer within a broader defense-in-depth strategy.

Imagine a scenario where an attacker successfully steals an authenticated Microsoft 365 session through an Adversary-in-the-Middle phishing attack. They authenticate to Exchange Online using the stolen session and open a PowerShell connection using the victim’s existing administrative permissions.

• Without additional controls, that attacker may have unrestricted administrative capability.
• With JEA, the same authenticated session may be limited to only a small subset of approved PowerShell cmdlets that support the administrator’s day-to-day responsibilities.
• The attacker still possesses an authenticated session.
• They simply no longer possess unrestricted administrative capability.

That distinction dramatically reduces the potential impact of the compromise.

Looking Beyond Identity

Microsoft has invested heavily in strengthening identity security over recent years through Microsoft Entra ID, Conditional Access, Continuous Access Evaluation, phishing-resistant authentication, Identity Protection, and Privileged Identity Management. Together, these technologies significantly reduce the likelihood of successful identity attacks. However, identity is only one component of the overall security architecture.

Organizations must also consider what happens after authentication succeeds. Administrative authorization, least privilege, endpoint security, application control, and continuous monitoring all become equally important once an attacker has obtained an authenticated session.

PowerShell Just Enough Administration addresses one of the final gaps in that architecture by restricting what administrators are allowed to execute rather than assuming every authenticated administrative session should automatically receive unrestricted access.

In a future post, we’ll take a detailed look at how PowerShell Just Enough Administration works, how session configurations and role capability files combine to create highly restricted administrative endpoints, and why JEA remains one of the most effective ways to reduce the impact of compromised administrative credentials in Windows Server and hybrid Microsoft environments.