AI Agents Come Home, While the Cloud Keeps Working

Perplexity's Agent Moves Onto the PC

A Windows AI agent can now work through sensitive files without routinely shipping them to the cloud. The catch is that the private part starts with a 24-gigabyte graphics card.

That trade-off is worth spending some time on, because it shows what local AI looks like once it moves beyond a model answering prompts. Perplexity Portable Computer became available through the Perplexity Windows app on 14 September. On compatible NVIDIA RTX hardware, the model, the agent harness and recurring workflows can run on the user's machine. The agent can analyse local files, use connected tools and carry out multistep jobs without consuming Perplexity Computer credits or routinely sending the underlying work to the cloud.

There's still a cloud route. When a task needs more advanced reasoning, the software can ask permission to send information off the device to a cloud model. That makes this a hybrid system rather than a sealed local appliance. The permission prompt is valuable, but its usefulness depends on whether the person approving it can tell what data is leaving, why it's needed and which connected service will receive it. A local model doesn't make a cloud escalation harmless, and a local agent with broad file and tool access can still do damage on the machine itself if its permissions are careless.

Running the model on the PC changes where the immediate analysis happens. It doesn't remove the other parts of an agent's trust boundary. The harness decides which steps to take, connectors can reach tools beyond the model, and recurring workflows may run when the user isn't actively watching each decision. For sensitive work, those layers deserve separate permissions. A developer may be comfortable letting the agent read one project directory locally but not letting a connector upload its contents, or letting a scheduled job prepare a result but not change an external system. Local compute gives that conversation a better starting point; it doesn't finish it.

The hardware floor narrows the audience sharply. Access requires a Perplexity Pro or Max subscription and a supported GeForce RTX or RTX PRO graphics processor with at least 24 gigabytes of video memory. Most ordinary Windows laptops and desktops don't qualify. For people who already own a high-end workstation, local execution may reduce routine cloud exposure without adding another dedicated AI box. For everyone else, the price of the GPU sits on top of the subscription. That keeps access limited to people who already own qualifying hardware or are willing to make a substantial hardware purchase.

There is also an evidence gap. NVIDIA and Perplexity describe the local workflow and permission-gated cloud path, but the briefing found no independent security assessment of the released Windows agent. So the privacy benefit is credible at the architectural level, not yet a blanket assurance about isolation, connectors or data handling.

My read is that this is a useful shift for developers handling sensitive code, documents or research on capable machines. Local agents are starting to offer more than offline chat. But privacy now depends on the whole path: local permissions, connector access and the exact moment a job crosses into the cloud.

Meta Sells More AI Inside Its Apps

That local option is specialised. Meta is putting a price on heavier AI use inside apps people open every day.

Meta announced Meta One on 15 September, a set of subscriptions spanning Instagram, Facebook, WhatsApp and Meta AI. The plans combine higher use of media-generation tools with consumer customisation and features for creators and businesses. Meta says its core apps and everyday Meta AI use will stay free, leaving a free layer in place across its social products. The paid layer is about more capacity and additional tools.

Advertised US pricing starts at two dollars ninety-nine a month for a single app. The Core bundle starts at seven dollars ninety-nine, while creator and business bundles start at fourteen dollars ninety-nine. For creators, that can mean expanded publishing and analytics features. Businesses can pay for more customer-agent capacity. Ordinary users are mainly being offered higher AI-generation limits and personalisation within Meta's existing services.

The missing number is important: Meta hasn't published the exact AI quotas for each tier. It says the plans are available globally, but rollout is gradual, and features, prices and account eligibility can vary by region, app and account. A headline monthly price therefore doesn't tell a user how much useful generation they're buying or whether the relevant feature has reached their account.

Meta's move says something about consumer AI economics. Model capability still matters, but packaging is becoming just as visible. The competitive question is increasingly whether an AI feature is included, metered, bundled across several products or reserved for a professional plan.

For people already working inside Meta's apps, paid capacity may be convenient because it removes a separate tool and workflow. The downside is lock-in: content generation, publishing, analytics and customer interactions become part of one subscription relationship. I wouldn't judge these plans by the starting price alone. The useful comparison is the work each tier permits once Meta discloses the limits and the rollout reaches the account that needs it.

Amazon's Agents Stay on the Job

The more consequential subscription question at work is what happens after the user closes the laptop. Amazon Quick now has agents that keep going.

AWS added cloud-hosted scheduled tasks and monitoring agents to Amazon Quick on 9 September. These agents can continue running in the cloud while the user's computer is off, then place their results in a feed. That changes the operating model from a person opening an assistant for a task to an organisation running persistent jobs in the background. Monitoring can continue across the day, and a scheduled workflow no longer depends on somebody keeping a session alive.

AWS paired that autonomy with more administrative controls. Organisations can set custom permissions for individual users, apply mobile-device management, connect Microsoft Purview data-loss-prevention policies and control how agents are shared. Those details are central to the release. An agent that wakes up on a schedule, reads workplace data and acts through connected tools needs a clear identity and a deliberately limited set of permissions.

The included usage also increased. Professional subscribers move from four to eight agent hours each month, and Enterprise subscribers move from eight to eighteen. That gives customers more room to use the background features, though it also makes agent time a resource administrators will need to track. A workflow that runs without a laptop can also consume hours without the user watching it happen.

AWS hasn't provided independent evidence about the reliability or error rate of these unattended jobs. That leaves an obvious question for organisations: how often does an agent need intervention, and what does it do when a source changes or a tool returns an unexpected result? The answer won't be the same for a monitoring feed and a workflow allowed to take an action.

Always-on agents can remove a fair amount of repetitive checking. They also turn permissions, audit records and spending controls into everyday operational work. Approvals work best at the level of each background job: what it can read, what it can change, how much time it can consume, and who reviews the result when nobody was present for the run.

School AI Rules Gain Contractual Teeth

A policy document can be easy to admire and hard to enforce. A new US school agreement tries to close that gap with contract terms.

Microsoft, the American Federation of Teachers and the United Federation of Teachers announced a National AI Safety and Privacy Standard on 9 September. US school districts can incorporate it into their Microsoft customer agreements, giving the protections a contractual basis rather than leaving them as voluntary principles. According to the Associated Press, the terms apply to schools under Microsoft contracts from 1 November 2026.

The agreement bars Microsoft from using student or educator data to train AI models, selling that data or repurposing it. AP reports a narrow exception connected to protecting students. The standard also calls for human oversight, transparency for families, third-party compliance audits and controls against AI experiences designed to manipulate users or encourage dependency.

For a school district, the practical change is leverage. Procurement staff can ask how a product handles data, require evidence through audits and seek remedies if the agreed protections are breached. Teachers and families get clearer terms to point to when they want to know whether classroom information can become training material or be used for another commercial purpose.

There are two firm limits. The agreement covers Microsoft, not every technology provider used in a school. And privacy terms don't answer whether a particular AI product helps students learn or belongs in a classroom. Those decisions still need educational evidence and local judgement. The real value of the standard will also depend on the quality of the audits and whether districts act when they find a problem.

Still, enforceable purchasing terms are a practical step. Schools buy technology through contracts, so contracts are one of the places where promises can become testable obligations. Education leaders can use this as a procurement baseline, then compare every other provider against the same questions. A strong Microsoft agreement leaves a gap if another classroom service can train on the same student data under weaker terms.

Cisco Email Gateways Under Active Attack

Now for a security issue that needs a much faster decision. Cisco says attackers are actively exploiting a critical flaw in its Secure Email Gateway.

CVE-2026-76461 is a SQL-injection vulnerability in the way the appliance parses email. An unauthenticated remote attacker can send a crafted message and potentially execute arbitrary commands with root privileges. That's the highest level of control on the system, and the device being targeted is supposed to sit in the path of hostile email.

Cisco gives the flaw a CVSS score of 9.8. Every physical and virtual Secure Email Gateway is affected when it runs a vulnerable AsyncOS release, regardless of how the appliance is configured. There is no workaround. Cisco has released fixed versions, which makes upgrading the immediate response rather than waiting for a setting that reduces exposure.

The incident work doesn't stop at patching. Cisco found possible signs of compromise on some cloud-managed devices and upgraded those appliances. It also warns that an attacker with root access may be able to hide or remove evidence. Operators therefore need to inspect logs held outside the gateway, not rely only on records stored on a machine an intruder may control. Cisco's guidance says a suspected virtual appliance should be treated as a rebuild and credential-rotation incident.

The company hasn't disclosed how many organisations were exploited, who is responsible or the full length of the campaign. That uncertainty shouldn't soften the response. Active exploitation, remote access without authentication and root-level execution are enough to put vulnerable gateways into the urgent queue.

There is a broader operational lesson here, but it's a very concrete one. A security appliance can become an entry point with privileged access to the environment it protects. Organisations running these gateways need the fixed AsyncOS release, off-device logs and a tested path to rebuild a virtual appliance without preserving a compromised state. External logging earns its keep in exactly this incident: the gateway's own story may be incomplete because the attacker had the authority to edit it.

A Compiler for Fault-Tolerant Quantum Work

From an urgent patch to a much longer technical horizon: NVIDIA is opening up software that helps researchers design fault-tolerant quantum systems.

CUDA-Q Logical is a new open-source layer in NVIDIA's CUDA-Q platform. It compiles and orchestrates logical quantum programs across different error-correction methods and hardware architectures. Fault tolerance is the effort to produce dependable computation from physical qubits that are themselves noisy. The hard part isn't only choosing an algorithm. Researchers need to map it through error-correction operations, physical schedules and real-time control while keeping track of the resources each choice consumes.

NVIDIA says the framework preserves compiler artefacts and assumptions across those layers. A researcher can trace how a logical program becomes error-correction microcode, then a schedule for physical operations and a control plan. Because the layer is retargetable, competing correction schemes and hardware designs can be compared without rebuilding the entire workflow by hand. Sandia's hardware-agnostic QUOPS benchmark is also available through CUDA-Q.

One early result is striking but needs the right label. NVIDIA says Fermilab reduced an architecture-development workflow from roughly five months to three weeks. That's an early collaborator result, not a broad benchmark proving every quantum project will see the same acceleration. The release is development infrastructure, not evidence that a generally useful fault-tolerant quantum computer has arrived.

The benefit is earlier, more repeatable comparison. Researchers can expose resource costs and design conflicts before committing to a physical architecture, when changes are cheaper. Open tooling also gives laboratories a shared object to inspect rather than hiding crucial assumptions in one-off calculations and scripts.

For quantum developers, that may be more useful right now than another isolated qubit headline. Better compiler provenance won't settle when fault-tolerant machines become commercially useful, but it can make the path towards them less manual and easier to challenge. The sensible measure of this release is whether different labs can reproduce resource estimates and make better hardware choices, not whether one early workflow moved dramatically faster.

GitHub Changes Model Routing and HTTPS

Two GitHub changes are worth putting together, because both can alter a developer's day without changing a line of application code.

First, Copilot's automatic model selector now offers three preferences: efficiency, balance and intelligence. Each tier draws from the same available model pool, and Copilot still chooses a model separately for every prompt. The preference changes how the selector weighs cost, response time and quality. It's rolling out across Visual Studio Code, Copilot CLI and the GitHub Copilot app.

Billing follows the model that Copilot actually selects. Paid subscribers keep a ten per cent discount on auto-selected usage, but the charge can still vary from one prompt to the next. That makes the new setting a useful expression of intent rather than a fixed budget. A developer can tell Copilot to lean towards cheaper or more capable choices without manually selecting a model every time, yet GitHub hasn't provided full visibility into why the router made each decision.

For people managing usage, the intelligence tier may suit a difficult task and the efficiency tier may suit routine work. The weak point is predictability. A cost preference becomes a real budget control only when the resulting model choice and charge are easy to see. Until then, teams will need to compare actual usage rather than assume the name of a tier sets a ceiling.

The second change is less visible until something breaks. On 15 September, GitHub disabled SHA-1 support in HTTPS and TLS for github.com and partner content-delivery networks. It applies to GitHub Enterprise Cloud, including Enterprise Cloud with Data Residency, but not GitHub Enterprise Server.

Old browsers, API clients and Git clients using HTTPS may now fail if their underlying TLS software can't negotiate newer algorithms. GitHub's advice is to update the browser, operating system, Git client and TLS libraries. For most current systems, nothing changes. Long-lived build machines and forgotten automation are the likely trouble spots.

That shutdown is a useful reminder for platform owners: cryptographic retirements arrive as dependency work. A secure service-side change can expose an old operating system or library overnight. If a pipeline suddenly lost GitHub access on 15 September, checking its TLS stack is more useful than repeatedly retrying the job.

What Changes for You

If you build on a high-end Windows machine, Perplexity's release creates one genuinely new option: a recurring, multistep agent can work over local files and connected tools without sending the underlying job to the cloud by default. The people who can use it today are Perplexity Pro or Max subscribers with a supported GeForce RTX or RTX PRO GPU carrying at least 24 gigabytes of video memory.

That can make scheduled work on sensitive code or documents more practical, especially when the machine already sits on your desk. It doesn't make the workflow fully offline or independently verified. Advanced reasoning can still move information to a cloud model after a permission request, connectors may reach external services, and no independent security assessment was identified. The machine also needs enough local access to complete the job, so the file boundary deserves the same attention as the cloud boundary.

So the useful change is control, not automatic privacy. Review the agent's local file and tool permissions, then treat every cloud escalation as a separate data decision. The subscription and GPU requirement keep this firmly in power-user territory, but developers with qualifying hardware can now test a local-first agent workflow without building the entire harness themselves.