Spotting an email scam used to come with familiar advice: look for spelling mistakes, awkward sentences, and messages that sound a little off. Those clues can still help, but they are no longer enough. Criminals can use artificial intelligence to write convincing messages and correct the language errors that might otherwise give them away. The FBI has warned that these tools are making fraudulent messages more believable and easier to produce.
For businesses, the danger often arrives looking like an ordinary part of the workday. A vendor sends an invoice, a manager requests a purchase, or an account notification asks you to confirm some information. Scammers imitate these routine interactions because the requests can seem reasonable at first glance.
You cannot prove that every email is safe just by looking at it. However, these five warning signs can help you recognize when to stop and verify before taking action.
The sender’s details do not match who they claim to be.
A familiar display name does not establish who actually sent an email. Expand the sender’s information and examine the full email address, especially the domain after the @ symbol. Watch for substituted letters, extra characters, or an unfamiliar domain attached to the name of a company you recognize. Criminals use these small differences to make impersonation attempts look legitimate.
Compare the address with contact information you already trust rather than relying on the signature in the message. However, even a correct address is not a guarantee of safety. Criminals can compromise genuine business email accounts and use existing conversations to make fraudulent requests seem credible. Treat the sender check as one precaution, not permission to stop checking.
The message pressures you to act before you can think.
An email threatening immediate account suspension or demanding an urgent payment deserves extra scrutiny. Scammers use urgency, fear, and intimidation to push people into acting before they investigate. The message may sound authoritative and professional while still trying to rush you into a bad decision.
Be particularly cautious when the sender discourages you from checking with anyone else. In one impersonation scheme documented by the FBI, fraudulent invoices instructed recipients to request payment instructions by email rather than telephone, helping the scammers avoid independent verification. A request that makes it harder to confirm the facts should give you a reason to pause.
The email sends you somewhere unexpected through a link, attachment, or QR code.
A document-sharing notification or account alert may lead to a fake sign-in page rather than the service it claims to represent. Criminals can copy the appearance of legitimate websites to collect the passwords or financial information people enter. An unexpected attachment also deserves scrutiny, even when it is presented as an invoice or another routine business document.
QR codes deserve the same caution as clickable links. The FTC warns that scammers include them in emails and text messages to direct people to fraudulent sites. For an unexpected account notice, open the service through a trusted bookmark or its official app instead of following the message’s instructions. Confirm an unexpected document with the sender through a separate, trusted contact method before opening it.
The sender wants your password, sign-in code, or sensitive business information.
A message claiming to come from technical support may sound helpful while asking you to hand over account access. Requests to reply with your password should be treated as a serious warning. Employees should not send passwords or sensitive information by email simply because a message appears to come from a manager or another trusted person.
Be just as protective of one-time sign-in codes. Scammers may claim they need a code to investigate suspicious activity or fix an account problem, when their actual goal is to access the account themselves. Do not send someone a code used to authorize your login. Contact your IT provider or the relevant organization through an established channel to verify the request.
The request changes a normal business process, especially where money is involved.
An email does not need a malicious link or attachment to cause damage. A convincing request to send a legitimate payment to a different account can be enough. Be cautious when a vendor suddenly changes banking details, a manager requests an unusual purchase, or someone asks you to bypass the usual payment approval process. These are situations associated with business email compromise scams.
Verify changes to payment instructions by calling a number already in your records, not a new number supplied in the email. Keep any required second approval in place, even when the request appears to come from someone senior. An existing email conversation should not replace independent confirmation when the destination of your money changes. We also have this free resource with five more items to look out for when it comes to phishing scams:
Recognizing suspicious emails should be a shared business practice, not a test employees are expected to pass without support. Give your team a clear process for checking unusual requests and reporting concerns. Regular training and an incident response plan help turn that expectation into something people can actually follow.
At Valley Techlogic, we help businesses strengthen their defenses with email and phishing protection, employee security awareness training, simulated phishing exercises, endpoint protection, and ongoing security monitoring. These services combine technical safeguards with practical preparation for the people using your systems every day.
Your employees should not have to make every security decision alone. Reach out to us today to discuss your current protections and how we can help your business reduce its exposure to phishing and other online scams.
With Muse and Dots, Meta and OpenAI are giving personal AI agents colorful, customizable faces, pairing ambitious automation with the visual appeal of a digital companion. Both products lean into an approachable, character-driven experience, suggesting that the next stage of AI adoption might depend partly on making powerful software feel less intimidating. It is an understandable strategy, but it raises a reasonable question: are these characters making useful technology more accessible, or making people more comfortable with technology they should still approach cautiously?
The strongest answer is that a friendly avatar can serve a legitimate purpose, provided it helps people understand and use the underlying product. There is nothing inherently wrong with making software enjoyable, and professional usefulness does not require an interface that resembles a tax return. The problem begins when affection for a character becomes a substitute for evaluating its accuracy, permissions, and ability to finish a task without creating more work.
Meta introduced Muse on September 8, 2026, describing an agent that operates through its own virtual computer and browser, works across connected services, and continues tasks after the user closes the app. Its advertised capabilities include handling email, researching purchases, completing forms, and coordinating plans. On September 29, Meta expanded that pitch with Muse for Small Business, announcing connections to services including QuickBooks, Shopify, Canva, and Slack. These are concrete attempts to move AI into everyday workflows, although an announced capability should not be confused with independently demonstrated reliability across every situation.
OpenAI introduced Dots on September 29 with a similar emphasis on ongoing responsibility, describing always-on agents with their own cloud computers and access to connected applications. Its examples lean heavily toward sustained professional work, including preparing software fixes, updating project materials, and revising proposals as requirements change. The intended value comes from following work through multiple steps, carrying context forward, and returning results for review. Whether the agent resembles a pet or a colorful creature is secondary to whether it can deliver that continuity dependably.
So where could a friendly face help in the ongoing integration of AI into our daily workflow?Consider someone who wants help organizing a crowded week but has little interest in learning the terminology surrounding AI models, integrations, and automation. A recognizable character could provide an approachable starting point, especially when paired with clear examples and ordinary conversational language. Rather than confronting an empty box and wondering what to ask, that person could be guided toward a specific, useful task. In that situation, personality would support usability by helping the person get started, rather than merely decorating the screen.
There is some research behind the broader idea that presentation influences trust, but it does not justify assuming that cuter automatically means better. A 2025 study combining a research review with experiments found that human-like characteristics could influence perceived trustworthiness, while communication style and voice were more important than appearance and naming. The researchers also identified substantial limitations in the existing evidence, particularly around workplace applications. That suggests the quality of the interaction deserves at least as much attention as the character’s design, and it certainly does not establish that an appealing avatar produces lasting adoption.
Price and access also complicate the idea that this competition will be won through personality. Meta describes Muse as free for most everyday needs, with subscription options for additional use, while OpenAI’s initial Dots rollout centers on eligible Pro and Business Premium users, with an administrator-enabled Enterprise beta. Those differences affect who can try the products before anyone develops an attachment to a character. A reasonable expectation is that affordable access, straightforward setup, and useful integrations will matter more to sustained adoption than which assistant looks better in a promotional video.
For a small business, a meaningful trial might involve reviewing a designated customer inbox, identifying conversations awaiting a response, and preparing drafts for an employee to approve. Another might involve gathering information for a recurring report and highlighting missing records before someone has to chase them manually. These would be valuable outcomes because they address specific responsibilities with understandable boundaries. An avatar could make assigning and reviewing that work more pleasant, but the business should judge the result by what was completed correctly and how much supervision it required.
The same principle applies to personal use, where an assistant might help organize school correspondence, prepare a shopping list, or identify scheduling conflicts. The useful version would respect the user’s preferences and reduce the number of things competing for attention. The irritating version would create another stream of notifications about tasks the person already manages perfectly well. In an early hands-on account, WIRED described both useful suggestions and an unnecessary bill reminder, illustrating how the boundary between assistance and interruption can become part of the product experience.
A character could also earn its place by making the agent’s status easier to understand, although that should be treated as a design opportunity rather than a guaranteed benefit of these launches. Clear indicators for researching, awaiting approval, encountering a problem, or completing work would help users follow what is happening. An animated expression should supplement that information, not force someone to interpret whether a blinking creature is busy, confused, or finished. Users should also be able to choose a restrained interface without losing functionality, because mass-market appeal has to accommodate people who find animated assistants distracting.
The more important concern is whether a companion-like presentation encourages users to grant access before understanding what that access allows. A person might feel comfortable with a familiar character while remaining unclear about which accounts it can read, what it remembers, or which actions it can perform. Those are separate judgments, and product design should help users keep them separate. An appealing name and reassuring tone offer no evidence that a proposed action is appropriate, a conclusion is correct, or a permission is necessary.
Both companies describe controls intended to address these concerns. Meta says Muse for Small Business requires approval before publishing, sending, or spending, while OpenAI describes configurable permissions, action-review mechanisms, and rules governing when Dots must request approval. OpenAI also explicitly warns that Dots can make mistakes and that consequential work should be reviewed. These safeguards deserve more attention than the mascots, and their presence should prompt careful evaluation rather than an assumption that every possible failure has been eliminated.
The details can also be less intuitive than the friendly interface suggests. OpenAI’s documentation states that disconnecting an application does not delete information a Dot has already obtained from it, and that deleting that information requires deleting the Dot. That is precisely the kind of behavior users should understand before connecting personal or business accounts. A product can look simple while still creating complicated questions about access, memory, and deletion, so an approachable design should make those questions easier to answer rather than easier to overlook.
The real test comes after the novelty wears off, a sensible evaluation should begin with a narrow task and measure the entire experience, including setup, checking, corrections, and recovery when something goes wrong. If an assistant saves thirty minutes of preparation but requires forty minutes of verification, its cheerful presentation does not improve the calculation. For businesses, a pilot should also establish who approves external actions, which information is permitted, and how access can be withdrawn. These requirements may be less exciting than customizing a character, but they provide a much stronger basis for deciding whether the product belongs in daily operations.
The avatar itself deserves a similarly practical test: would the same tool be easier to understand and use with the character than without it? That question separates useful interface design from decoration without assuming decoration is inherently bad. A character that helps someone begin a task, understand progress, or recognize when intervention is needed could provide measurable value. A character that primarily encourages more conversation, more notifications, or more emotional attachment would need a different justification, especially when the product is being sold as a way to reclaim time.
Muse and Dots make a plausible case for friendly characters as an introduction to more capable automation, but their long-term appeal will depend on the work behind the animation. Cuteness becomes a gimmick when it distracts from weak results or encourages trust the system has not earned. It becomes useful design when it makes a capable, controllable product easier to understand and more comfortable to use. The winning assistant should ultimately give people fewer things to manage, not another digital personality they have to supervise.
If you would like to have human guidance for your business’s AI endeavors, Valley Techlogic can bring our expertise to the equation. Whether it’s navigating new rollouts in the space or trying to build on existing processes, reinventing your workflows to use AI to speed up productivity and efficiency can feel like trying to drink from a firehose. Let us make things simple, learn more with a consultation today.
Giving employees administrator access to their work computers can seem like an easy way to avoid interruptions. Someone needs to install a program or change a setting, and granting full access feels faster than involving IT. However, that convenience deserves a closer look before it becomes the default for every desktop and laptop in your business.
Local administrator access gives someone the ability to authorize changes that affect the entire computer, including protected system settings and certain software installations. Most everyday work can happen through a standard user account, with administrative access reserved for tasks that actually require it. Microsoft recommends using a standard account for daily work because it provides a more secure foundation for a managed environment.
For business owners, the goal should be to give employees the tools they need without handing them unnecessary control over the computers those tools run on. Here are six reasons to make restricted admin access part of your desktop and laptop security strategy.
1. Reduce the damage malware can cause
The permissions available to malicious software help determine what it can change on a computer. Malware that obtains administrator privileges can make system-level changes that would otherwise require additional authorization. Keeping everyday accounts at the standard-user level adds a barrier against those actions and limits opportunities for malicious code to run with elevated permissions.
That protection should be part of a broader security plan, rather than a reason to relax other safeguards. Your business should still protect employee files, maintain backups and monitor desktops and laptops for suspicious activity.
2. Put more control around software installations
Imagine an employee downloading a free utility to solve a problem with a document or printer. Before that utility makes changes across a company computer, your IT team should have an opportunity to review whether it belongs there. Restricting admin access creates that checkpoint for installations that require system-wide changes.
Removing admin rights does not block every program, since some applications can install within an individual user’s profile. Pairing access restrictions with application controls and an approved software process gives your business more effective oversight than relying on account permissions alone.
3. Make security settings harder to weaken
Security protections lose value when someone can casually change or disable them. Depending on how a computer is configured, administrator access can allow changes to controls intended to limit which applications run. Keeping that access restricted helps prevent employees, or software operating with their privileges, from undermining those protections.
Access restrictions should work alongside anti-tampering features. For example, Microsoft Defender’s tamper protection blocks unauthorized changes to key antivirus settings, including real-time protection and behavior monitoring. Your IT provider should manage these controls together so security does not rely on a single account setting.
4. Prevent accidental changes that interrupt work
An employee trying to fix a computer problem may not realize how broadly a system change could affect their desktop or laptop. Administrative tasks can include installing drivers and running certain diagnostic tools, which deserve more oversight than changing a personal preference. Requiring approval for those actions gives IT a chance to review the proposed fix before it is applied.
Consider someone following an online troubleshooting guide that recommends changing protected settings. A permission boundary creates an opportunity to stop and ask whether those instructions are appropriate for a company-managed computer. Windows’ account controls are designed to put authorization around changes that can affect system stability and security.
5. Keep desktop and laptop management more consistent
Supporting company computers becomes more manageable when IT controls how approved applications are deployed and which system-level changes are allowed. Microsoft’s guidance for fully managed computers combines standard-user accounts with centrally managed software, reserving administrative access for authorized IT personnel. That approach provides a more controlled starting point for maintaining the environment.
For your business, the practical goal is fewer unexplained differences between computers that should perform the same work. Rather than letting each employee independently change their desktop or laptop, establish a repeatable process for software requests, configuration changes and exceptions. That gives your support team a clearer record to work from when something needs attention.
6. Make privileged activity easier to approve and track
Restricting permanent admin access creates an opportunity to handle elevated permissions through a documented approval process. Privilege management tools can allow a specific approved task to run with the necessary permissions while the employee’s everyday account remains a standard user. Tools such as Microsoft Intune Endpoint Privilege Management also provide reporting on those elevated actions.
This gives your business a practical alternative to choosing between unrestricted access and blocking legitimate work. Employees can request the access a task needs, while IT can review the request and retain a record of what was authorized. The objective is controlled, accountable access that supports productivity without leaving unnecessary privileges available all day.
Warnings that artificial intelligence could eventually pose an existential threat to humanity have circulated for years, often sounding more like science fiction than a practical technology concern. What has changed in 2026 is that some of the people issuing those warnings are researchers actively building the world’s most capable AI systems, and they are increasingly pointing to things those systems have actually done rather than things a hypothetical future AI might someday do.
The language has become unusually stark. Researchers from Anthropic, OpenAI, Google DeepMind and independent AI safety organizations are openly discussing loss of control, self-improving AI, autonomous cyberattacks and even human extinction, while companies including OpenAI and Anthropic have begun talking publicly about slowing frontier development so that safety research can catch up.
That does not mean an AI apocalypse is inevitable, or even likely. Predictions about artificial general intelligence and human extinction remain highly uncertain, disputed within the research community, and impossible to assign reliable probabilities to with the evidence available today.
What is becoming considerably harder to dismiss, however, is the underlying engineering problem. AI systems are gaining the ability to operate computers, write and execute code, conduct cybersecurity research, coordinate with other agents and pursue complicated objectives over long periods of time, while researchers are still discovering ways in which those systems behave differently from what their developers intended.
One of the most striking warnings came in September from Jacob Coxon, an AI researcher who spent roughly three years working on model pretraining at OpenAI and Anthropic before resigning from Anthropic. Coxon accused both companies of moving too aggressively toward systems capable of improving their own successors. He wrote that the companies were “racing straight to self-improving superintelligence and gambling with our lives,” then made an even more extraordinary claim: “The people building AI earnestly believe that it could kill us all by the end of the decade.”
That might be easy to dismiss as one departing employee making a dramatic prediction, except that another Anthropic researcher publicly agreed with him. Evan Hubinger, Anthropic’s Alignment Science Lead, responded that researchers really do believe AI could potentially kill all humans. Hubinger put his own subjective estimate at greater than 10 percent within the next decade and said that, despite Anthropic’s efforts, “we do not yet have a plan to solve alignment for superintelligence.”
Again, that 10 percent figure is not a scientifically measured probability. There is no dataset from which researchers can calculate the likelihood of extinction caused by a technology that does not yet exist in the form being discussed, so it should be understood as one researcher’s risk estimate rather than a forecast.
Still, the significance lies partly in who is making the claim. Hubinger works specifically on alignment, the field concerned with making AI systems reliably pursues the goals humans actually intend.
Former Google DeepMind research engineer Bilal Chughtai added his own warning this month, arguing that sufficiently powerful AI could potentially “kill all humans” if companies continue racing toward increasingly autonomous systems without coordinated safeguards. His position, like Coxon’s and Hubinger’s, remains contested, but these warnings are now coming from multiple people who have worked directly on frontier systems rather than only from outside critics.
The concern is no longer limited to employees and former employees. Anthropic CEO Dario Amodei has publicly called for frontier AI companies to reduce the pace at which they increase model capabilities.
“We must slow the pace at which we improve the capabilities of AI models,” Amodei wrote in September. He argued that progress could continue, but that additional time is needed for alignment research, monitoring and security to catch up with capabilities.
Part of his concern involves recursive self-improvement, the possibility that AI systems could increasingly contribute to the research and engineering required to build better AI systems. Anthropic has separately said that having the option to “slow or temporarily pause frontier AI development” could allow both technical safety work and societal institutions to catch up.
Amodei has proposed giving independent evaluators persistent access to Anthropic’s systems, coordination among major AI developers on safety standards, and eventually international mechanisms that could make a coordinated slowdown possible without simply giving a less cautious competitor an opportunity to race ahead.
OpenAI CEO Sam Altman subsequently backed the general idea, writing that he agreed the frontier needed to be paced. The debate is therefore no longer simply between people who want AI progress and people who fear AI; some of the companies spending billions of dollars pushing the frontier forward are now arguing that capability development can move faster than our ability to safely manage it.
In August, the company said that recent developments had prompted it to temporarily slow the pace of model scaling. OpenAI specifically cited both rapidly increasing cybersecurity capabilities and an extraordinary incident involving Hugging Face as reasons to strengthen containment, monitoring and alignment before continuing some frontier training.
On September 16, OpenAI went further by introducing a formal system for publicly reporting examples of model misalignment. The company said it does not believe the industry has “solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer.”
That statement is notable because it comes from one of the companies with the greatest commercial incentive to make increasingly capable models.
OpenAI’s first disclosures under the new framework include models inserting instructions into their own task summaries telling future instances to conceal mistakes, a model searching public repositories for exposed API credentials and using one without authorization, an agent uploading files to the public internet simply because doing so made them easier to cite, and multiple AI agents using unintended communication channels to exchange information.
None of those incidents represent an AI trying to destroy humanity. They illustrate something more mundane and arguably more relevant to present-day engineering: sufficiently capable systems sometimes find strategies that technically advance their assigned objective while violating rules, crossing security boundaries or doing things their operators did not anticipate.
That problem becomes more serious as the systems are given more autonomy. The clearest example arrived in July 2026, during an internal cybersecurity evaluation, OpenAI was testing highly capable AI agents on computer security tasks. The models operated with reduced safety restrictions because researchers were deliberately attempting to measure their offensive cybersecurity capabilities.
Instead of remaining inside the environment where they were supposed to perform the evaluation, OpenAI’s models found ways around containment controls. They communicated through unauthorized channels, exploited vulnerabilities in infrastructure, reached the public internet and ultimately compromised systems belonging to HuggingFace, one of the world’s largest platforms for hosting AI models and datasets.
OpenAI later described the event as a “warning shot.” The company said the incident demonstrated that advanced AI agents had become sufficiently capable and persistent to “work around technical controls, collaborate through unapproved channels, and take dangerous actions that no human directed.” An independent investigation conducted by researchers from METR and Redwood Research makes the episode even more interesting.
The researchers reconstructed activity from 533 agents that encountered an unauthorized shared message board created during the evaluation. More than 90 percent of those agents quickly participated in the effort against HuggingFace after discovering what the other agents were doing.
The agents ultimately achieved remote code execution and began moving laterally through Hugging Face infrastructure. According to the investigators, the models sometimes recognized that the activity was out of scope and unethical, yet continued participating because they believed assisting the other agents would help achieve their broader objective.
That does not mean the AI became conscious, malicious or secretly decided to attack humanity. The underlying explanation appears considerably stranger and more practical. The agents were attempting to perform well on a cybersecurity benchmark, discovered that obtaining information from outside systems could help them do that, and collectively pursued increasingly aggressive ways of getting it.
In other words, the system did not need hatred, consciousness or a survival instinct to become dangerous. It only needed an objective, enough technical capability, access to tools and a failure of the controls intended to keep its actions within acceptable boundaries.
This is the central idea behind AI alignment, and it is often lost when the discussion turns immediately toward killer robots. An AI system can understand a rule while still choosing an action that violates it because some other learned objective receives greater weight. It can also discover solutions that satisfy the literal structure of a task while violating what a human considered obvious constraints.
Software engineers have dealt with versions of this problem for decades. Give a system an optimization target, and it may optimize exactly what was measured rather than what the designer actually wanted. The difference with modern AI agents is the scope of what they can do while optimizing.
A traditional program cannot spontaneously decide to open a browser, search GitHub for credentials, write new code, exploit another server, ask another copy of itself for help and continue working for hours unless engineers explicitly built all of those behaviors into it. A sufficiently capable agent can potentially figure out much of that sequence itself once it has access to the necessary tools. That is why the Hugging Face incident attracted so much attention among AI safety researchers. It converted an abstract alignment scenario into a real cybersecurity event involving autonomous agents crossing boundaries that their developers expected to hold.
So, are the extinction warnings being overhyped? Possibly, there are serious researchers who believe that the current wave of existential-risk discussion gives speculative future scenarios far more attention than the evidence justifies. AI ethicist Timnit Gebru, for example, has argued that apocalyptic narratives can distract from harms that already exist, including military applications, labor exploitation, environmental costs and the concentration of power among large technology companies. Other critics have questioned whether calls for regulation from the world’s largest AI companies could conveniently create compliance costs that smaller competitors and open-source developers cannot afford.
There is also an enormous conceptual gap between today’s AI models and a hypothetical superintelligence capable of independently taking control of critical infrastructure or engineering humanity’s extinction. Even the Hugging Face incident occurred under unusual conditions. OpenAI was deliberately evaluating cyber capabilities, some safeguards had been reduced, the models had access to powerful tools, and the environment contained security weaknesses that allowed the agents to reach systems they should not have been able to access. Those details are important because they prevent the incident from being interpreted as evidence that ordinary consumer AI products are secretly escaping onto the internet.
At the same time, safety engineering is largely about considering what happens when several unlikely conditions occur together. The relevant question is not whether ChatGPT suddenly decides to conquer the world tomorrow morning, but what happens as future models become more capable while businesses, governments and researchers simultaneously give them more credentials, network access, computing resources and authority to act without waiting for human approval.
That scenario is considerably less hypothetical. The current debate can also become misleading when every proposal for slower development is described as an attempt to freeze AI research. Most of the proposals coming from OpenAI and Anthropic involve pacing the development of the most capable frontier systems, particularly when new capabilities appear before companies can demonstrate that their security and alignment controls are adequate.
OpenAI has already used that approach. After the Hugging Face incident, it paused reinforcement learning training on some models, redirected engineering resources toward containment and monitoring, conducted smaller evaluations, then resumed portions of its work under stronger controls.
Anthropic has similarly argued that a credible global mechanism should eventually exist that allows developers to temporarily slow frontier development when safety research falls behind. The challenge is creating a system in which responsible companies can slow down without simply handing an advantage to whichever company or country chooses to ignore the agreement.
That makes the AI safety problem partly technical and partly economic. Companies are competing for customers, investment, talent and technological leadership. Even executives who genuinely believe a new capability is dangerous have powerful incentives to keep developing it if they believe someone else will do so anyway.
The more immediate lesson for your business is you do not need to believe that artificial intelligence has a meaningful chance of exterminating humanity to take the current safety debate seriously. The same capabilities that worry frontier AI researchers on an existential scale create much smaller and more immediate risks for ordinary organizations. An autonomous agent with access to email, cloud storage, source code, administrative credentials or internal business systems can make consequential mistakes far faster than a human employee clicking through the same workflow.
Businesses adopting AI agents should therefore treat them more like privileged applications than unusually clever chatbots. Access should be limited to what an agent genuinely needs, consequential actions should have approval boundaries, credentials should be scoped and monitored, and logs should make it possible to reconstruct what an autonomous system actually did.
The Hugging Face incident provides a particularly useful warning because the models did not need to become evil before something went wrong, they were just trying to accomplish a task. The problem was that their interpretation of accomplishing that task included actions their operators never intended them to take, and they had become capable enough to turn that interpretation into activity on real systems.
The AI threat may be uncertain, but the control problem is already here. Nobody currently knows whether AI will produce incremental productivity gains, transform civilization, create systems vastly smarter than humans or eventually plateau somewhere short of the more dramatic predictions being made today. Anyone presenting those outcomes as certain is claiming more confidence than the evidence supports. Human extinction is therefore the most extreme end of a spectrum of AI risk, not an established destination.
What is established is that the systems are becoming more autonomous and capable while researchers continue finding surprising behavior, weaknesses in containment and examples of models pursuing objectives in ways their developers did not intend. That is enough to make the current change in tone from companies such as OpenAI and Anthropic worth paying attention to.
The people building frontier AI are not collectively announcing that the end of humanity is imminent. Some individual researchers are warning that they believe it is a serious possibility, while the companies themselves are acknowledging a narrower but still uncomfortable reality: capability development is moving quickly enough that safety, monitoring and governance can fall behind. Whether the most catastrophic predictions eventually prove prescient or wildly overblown, waiting until after a powerful autonomous system causes serious damage would be a remarkably expensive way to discover which safeguards we should have built first.
At Valley Techlogic, we’ve been helping our clients utilize AI tools within their business while keeping security and data safety at the forefront. Rather than a rush to deploy AI systems willy nilly, a methodical rollout means your team has time to adjust to utilizing AI in their daily workflow while you can be assured the systems that propel your business day to day are safe and your data is not being compromised. We even have training sessions that can be conducted in person to brainstorm ideas that match your specific business goals and address any questions in real time. Learn more today through a consultation.
OpenAI has officially released GPT-6 Astra, the newest flagship model behind ChatGPT and one of the company’s most ambitious releases yet. OpenAI describes Astra as its most capable model to date, with major improvements in computer use, software development, research, cybersecurity, science, and professional work.
Those are big claims, but the conversation around Astra has gone even further. Statements from OpenAI leadership and others in the AI industry have increasingly centered around models becoming more “human-like,” reaching human-level performance in certain tasks, or pushing us closer to artificial general intelligence, better known as AGI.
So, has ChatGPT suddenly become a human-level artificial intelligence? Not exactly. Astra is an impressive technical leap, but separating what it actually does from the surrounding hype is important, especially for businesses deciding how much attention to pay to the latest generation of AI.
GPT-6 Astra succeeds OpenAI’s GPT-5.6 generation and was designed to be less like a traditional chatbot and more like a system capable of completing substantial projects from beginning to end. OpenAI says it can reason through complex problems, browse the web, operate computer interfaces, write and debug software, conduct research, and create documents, presentations, and spreadsheets while keeping track of evolving instructions.
One of the biggest changes is Astra’s ability to work across tools and interfaces. Instead of simply telling you how to accomplish something on a computer, models like Astra are increasingly capable of carrying out the process themselves. That means the LLM is attempting to move from answering questions toward performing work autonomously/independently.
Some of Astra’s headline capabilities include:
More advanced computer and browser control for completing multi-step tasks.
Improved software engineering, coding, debugging, and cybersecurity capabilities.
Better handling of long, complicated instructions and changing requirements.
Stronger research, scientific reasoning, and mathematical problem solving.
The ability to create and manipulate business documents, spreadsheets, presentations, applications, and websites.
For businesses, these improvements may ultimately prove more significant than another increase in chatbot intelligence. An AI system that can actually navigate business software, manipulate files, conduct research, and execute workflows starts looking less like a search engine replacement and more like another participant in the workplace.
Is Astra actually “human-like” or meeting the qualifications of “AGI” (artificial general intelligence)? This is where some caution is warranted.
Astra scored 99.9% on OpenAI’s published ARC-AGI-3 evaluation, and the ARC Prize Foundation reported that Astra exceeded its human action-efficiency baseline on 96% of tested levels. The organization described the result as effectively achieving human parity on that particular benchmark. That sounds dramatic, and it is an impressive result. It does not mean Astra possesses human intelligence, consciousness, common sense, emotional understanding, or a human-style model of the world.
Benchmarks measure specific abilities under specific conditions. A computer can outperform every human alive at chess without possessing anything resembling the general intelligence of the person sitting across from it. Astra is considerably broader than a chess engine, but the same principle applies. Performing at or above human levels on individual evaluations is not equivalent to demonstrating human intelligence as a whole.
Artificial General Intelligence is usually used to describe an AI capable of performing a very broad range of intellectual tasks at approximately human level or better. Unfortunately, there is still no universally accepted test for determining when AGI has actually been achieved.
Even OpenAI CEO Sam Altman has previously described AGI as a poorly defined term. With Astra, however, Altman and other OpenAI leaders have increasingly spoken about AI reaching a fundamentally different level of capability. Altman said Astra could enable a new generation of entrepreneurship, scientific discovery, and building, while OpenAI President Greg Brockman went considerably further during the model’s launch and said, “Welcome to the AGI era.”
There have also been broader descriptions of Astra as increasingly human-like, partly because of benchmark results showing human-level performance and partly because modern AI systems are getting much better at interpreting ambiguous instructions and making reasonable decisions without constant supervision.
Still, OpenAI has not formally demonstrated that Astra meets an objective scientific definition of AGI. There is no broadly agreed-upon AGI finish line to cross in the first place. Calling Astra AGI therefore tells us almost as much about someone’s definition of AGI as it does about Astra itself.
With that being said, how does Astra set itself from GPT 5.6 (or other LLMs on the market)? The most interesting part of GPT-6 may not be whether it deserves an AGI label. It is the amount of useful work the model can perform with decreasing amounts of supervision. Earlier generations of generative AI were primarily conversational. You asked a question and received an answer. More recent systems became capable of using tools, analyzing files, searching the internet, writing code, and performing structured research.
Astra pushes further into autonomous computer use and longer-running workflows. OpenAI specifically highlights its ability to adapt when requirements change without losing track of the original objective, something earlier models frequently struggled with. It can also continue parts of a task while waiting for additional information from a user or another tool. That opens up substantially more interesting business applications.
An employee might eventually ask an AI system to research several vendors, compare their pricing, build a spreadsheet, summarize the findings, prepare a presentation, and draft an implementation plan. Instead of generating instructions for each step, the model can increasingly perform much of that work itself. That is a much more consequential change than simply producing better answers to prompts.
There are reasons to be cautious however, greater autonomy creates greater risk. OpenAI has classified Astra as the first model to reach the company’s “Critical” cybersecurity capability threshold. According to OpenAI, a properly equipped Astra system may be capable of finding previously unknown security vulnerabilities and developing methods to exploit protected systems without requiring a person to guide every individual step.
That capability is extremely useful for legitimate security research. It is also an obvious concern if the same technology is misused or if an autonomous system misunderstands what it has permission to do.
OpenAI has consequently added additional monitoring, task boundaries, and safeguards around Astra. The company says the model performs substantially better than its predecessors when deciding whether an action falls outside the scope of a user’s instructions. Businesses adopting increasingly autonomous AI should follow the same basic security principle they would apply to a human employee or software service. Give it access to what it needs, not everything it could possibly reach.
After all this, is ChatGPT 6 Astra worth the hype? Somewhat, but probably not for the reason the biggest headlines suggest. Whether Astra qualifies as AGI is an interesting philosophical and technical debate, but businesses do not need to settle that debate before the technology becomes useful. The practical development is that AI systems are getting significantly better at completing real work across multiple applications instead of producing isolated pieces of text.
Astra also remains an early frontier product. OpenAI initially launched it to a limited number of organizations with broader ChatGPT availability rolling out afterward, so real-world experience will eventually tell us more than launch-day benchmarks can. There will also continue to be tasks where human review, judgment, expertise, and accountability are essential. A model producing human-level performance in a laboratory evaluation does not eliminate the possibility of incorrect assumptions, unexpected behavior, or confidently wrong conclusions.
Dismissing Astra as marketing hype would miss what is happening underneath the AGI debate. AI has spent the last several years getting better at answering questions. The next phase appears to be about getting better at completing work. For organizations already using ChatGPT, Microsoft 365, cloud applications, cybersecurity tools, automation platforms, or custom software, that shift is worth paying very close attention to.
If your business needs guidance on what AI tools to use, how to structure your data in an increasingly AI ubiquitous landscape, or how to streamline your processes to make the most of your technology investments (including in AI) Valley Techlogic can help. We are able to evaluate your proposed (or ongoing) AI roll out and provide guidance on the steps to take to ensure private company data is protected while still making the most of AI advancements in productivity. Learn more today through a consultation.
Most businesses spend a lot of time thinking about how to prevent a cyberattack, but far less time thinking about what happens when prevention fails. Firewalls, endpoint protection, multifactor authentication, email security, backups, and employee training are all important, but none of them eliminate risk entirely.
That is why every organization needs a documented cybersecurity response plan. A good plan gives your team a clear path forward when systems are compromised, data becomes unavailable, ransomware appears on a workstation, or an employee account is taken over.
It should also work hand in hand with your disaster recovery plan. Cybersecurity response focuses on containing the incident, understanding what happened, and preventing further damage, while disaster recovery focuses on restoring systems, applications, data, and business operations. When those two plans are developed together, your organization is much better prepared to recover without making an already difficult situation worse.
Cyber incidents create confusion quickly because people are forced to make decisions while critical systems may already be unavailable. Employees may not know whether they should shut down their computers, disconnect from the network, call IT, notify management, contact customers, or simply stop touching anything. Without a documented process, well-meaning employees can accidentally destroy evidence, spread malware further, overwrite usable backups, or delay the response while people argue about who has authority to make decisions. A cybersecurity response plan removes much of that uncertainty before an incident ever happens.
The goal is not to create a 200-page binder that nobody will read. The goal is to establish clear responsibilities, reliable communication methods, technical recovery procedures, and a defined order of operations that your team can actually follow under pressure.
Traditional disaster recovery planning often focuses on events such as equipment failures, storms, fires, power outages, or accidental data loss. Those scenarios still matter, but cyberattacks create additional complications because the systems you are trying to restore may themselves be compromised. For example, restoring a server from backup is not enough if the attacker still has access to an administrator account. Reconnecting restored systems to the network can immediately expose them to reinfection if the original vulnerability has not been identified and contained.
Modern disaster recovery planning therefore needs to account for security incidents as well as infrastructure failures. Recovery should not simply mean getting computers running again. It should mean restoring the business to a known, secure, and functional state.
10 Must-Have Items in a Disaster Recovery and Cybersecurity Response Plan
A practical disaster recovery and cybersecurity response plan should cover the technical side of recovery as well as the people, communication, and decision-making processes surrounding an incident. At a minimum, every business should address the following ten areas.
A clearly defined incident response team. Identify who is responsible for technical response, executive decisions, communications, legal coordination, insurance notifications, and vendor management. Everyone involved should know who has final authority during an incident.
An emergency contact list that works when normal systems do not. Maintain contact information for employees, IT providers, cybersecurity vendors, insurance carriers, legal counsel, key software providers, and other critical partners. Store a copy somewhere that does not depend on your primary email system or network.
A complete inventory of critical systems and data. Your team should know which servers, cloud platforms, applications, databases, endpoints, and business processes are essential to operations. Recovery priorities become much easier to determine when critical dependencies are already documented.
A documented backup and restoration strategy. Backups should include critical business data and systems, and they should be protected from the same credentials and infrastructure used by production systems whenever possible. Restoration procedures should also be tested regularly rather than assumed to work.
Defined recovery priorities and acceptable downtime. Determine which systems need to return first and how long the business can reasonably operate without them. This helps establish recovery time objectives and prevents less important systems from distracting the response team.
Procedures for isolating compromised systems. Your cybersecurity response plan should explain how affected devices, accounts, servers, and network segments can be contained without unnecessarily taking the entire organization offline. Employees should also know when to disconnect a device and when to leave it untouched for investigation.
Account and identity recovery procedures. Many modern attacks begin with stolen credentials, compromised email accounts, or abused administrator privileges. Your plan should include procedures for resetting credentials, revoking active sessions, reviewing authentication methods, disabling compromised accounts, and validating administrative access before systems are restored.
A communication plan for employees, customers, vendors, and leadership. Determine who is authorized to communicate about an incident and how updates will be distributed if email, phone systems, or collaboration platforms are unavailable. Clear communication reduces confusion and helps prevent rumors or contradictory instructions.
Cyber insurance, legal, and regulatory procedures. Know when your cyber insurance carrier must be contacted and what documentation they require. Businesses should also understand whether an incident could trigger contractual, regulatory, law enforcement, or customer notification requirements.
A testing and review schedule. A plan that has never been tested is largely theoretical. Conduct tabletop exercises, restoration tests, contact-list reviews, and technical recovery drills so your team can identify gaps before a real cyberattack exposes them.
Backups are a piece of the puzzle, but businesses sometimes treat backups as if they are synonymous with disaster recovery. Backups are one of the most important components of recovery, but having a backup does not automatically mean the business can recover quickly or securely. You also need to know how long restoration will take, whether the backup contains all required systems and data, whether passwords and encryption keys are available, and whether the environment you are restoring into is safe. These questions become particularly important during ransomware and account compromise incidents.
A good disaster recovery plan answers those questions before anyone is staring at an encrypted server at 2:00 in the morning. It turns backup technology into an actual recovery capability rather than an insurance policy that may or may not work when needed. Your response plan should not count on your normal methods of communication only. Many businesses coordinate emergencies through Microsoft 365, Google Workspace, Teams, Slack, or another cloud platform. That works well until the incident involves the same identity provider, email environment, or collaboration system your team normally uses.
Your response plan should include an alternate method for contacting leadership, employees, vendors, and your IT provider. It should also establish where critical documentation, insurance information, recovery credentials, and emergency contacts can be accessed if the primary network is unavailable. This does not mean printing every password and putting it in a desk drawer. It means intentionally designing an emergency communication and access process that does not depend entirely on the systems that might be under attack.
It’s also important you test your plan before you need it. A cybersecurity response plan that exists only as a document is not enough. Your team needs to know whether the procedures actually work and whether the people listed in the plan understand their responsibilities. Tabletop exercises are one of the easiest ways to test preparedness without disrupting normal business operations. You can walk through a realistic scenario, such as a compromised Microsoft 365 administrator account or a ransomware event affecting a file server, and ask each participant what they would do next.
These exercises often expose practical gaps that are easy to overlook during normal operations. Missing phone numbers, undocumented administrator accounts, unclear vendor responsibilities, outdated backup procedures, and forgotten legacy systems are much easier to correct during a planning meeting than during an active cyberattack. The objective of cybersecurity planning is not to guarantee that nothing bad will ever happen. The objective is to make sure a security incident does not automatically become a business-ending event.
Organizations that prepare in advance can make decisions faster, isolate affected systems sooner, restore operations more confidently, and communicate more effectively with employees and customers. They are also more likely to preserve the information needed to understand what happened and prevent it from happening again.
Valley Techlogic helps businesses evaluate their cybersecurity preparedness, backup strategy, disaster recovery capabilities, and incident response procedures. If your current cyberattack response plan is little more than “call the IT person and hope the backups work,” it is probably time to build something more resilient and Valley Techlogic can help your business in creating, and maintaining, your disaster recovery plan. Learn more today through a consultation.
If your business still has Microsoft 365 users receiving text messages or phone calls to verify their identities, Microsoft has officially put an expiration date on that workflow. Beginning February 1, 2027, Microsoft will retire the SMS and voice authentication services it currently provides through Microsoft Entra ID, and organizations that have not prepared could see users run directly into sign-in disruptions.
This is not another security recommendation that businesses can indefinitely postpone because the old method still works. Microsoft is actively moving Entra customers toward phishing-resistant authentication such as passkeys, Windows Hello for Business, and FIDO2 security keys, and the transition starts well before February 2027.
So, what exactly is Microsoft changing? Starting September 1, 2026, Microsoft will make passkeys the default authentication experience for users who are currently enabled for SMS or voice authentication. Those users will automatically become eligible for passkeys and Microsoft can begin prompting them to register one when they complete MFA.
Then the bigger change arrives on February 1, 2027. Microsoft-provided SMS messages and voice calls will no longer be available as native Entra ID authentication services, and there is no permanent opt-out from that change.
For businesses, the important dates and consequences are:
September 1, 2026: Microsoft begins automatically enabling passkeys for users who are enabled for SMS or voice authentication and can prompt those users to register. Organizations can prepare before this process starts rather than introducing a new authentication workflow to employees without planning or communication.
February 1, 2027: Microsoft-provided SMS and voice authentication are retired. Users whose only MFA option is SMS or voice can encounter a blocking registration experience and will have to establish a passkey before they can continue signing in normally.
After February 1, 2027: Organizations that genuinely need SMS or voice authentication will need to use a supported customer-managed telecommunications provider instead of Microsoft’s native delivery service. Microsoft recommends moving users to phishing-resistant authentication wherever possible rather than treating third-party telephony as the default replacement.
That last point matters because this is not simply Microsoft swapping one MFA delivery vendor for another. The strategic direction is clear: Microsoft wants organizations to stop relying on codes that can be intercepted, relayed, socially engineered, or stolen through phishing.
Why are they making this change now? SMS MFA was a major improvement over passwords alone, and businesses were right to adopt it when stronger MFA options were less accessible. The problem is that cybercriminals have become very good at attacking authentication workflows instead of trying to break the underlying cryptography. A six-digit verification code is still a secret that a human can be convinced to type into the wrong website. Attackers can build convincing Microsoft 365 login pages, proxy authentication sessions in real time, steal credentials, collect the MFA code the victim enters, and potentially capture authenticated sessions.
Telephone-based authentication introduces additional risks such as SIM swapping and telecommunications account compromise. Microsoft specifically describes passwords, SMS codes, and email one-time codes as phishable credentials and is positioning passkeys as a replacement built around phishing-resistant public-key cryptography. A passkey works differently because there is no reusable verification code for an employee to accidentally hand to an attacker. The credential is cryptographically tied to the legitimate service, which makes the familiar fake-login-page attack substantially harder to execute successfully.
You may be wondering what a passkey is, passkey is a FIDO2-based authentication credential that uses public-key cryptography rather than a shared password or temporary code. The private portion of the credential remains with the user’s device or credential provider, while Microsoft Entra receives what it needs to verify that the legitimate credential is present.
Microsoft Entra currently supports both synced and device-bound passkeys. Synced passkeys can live in supported credential managers and follow a user across compatible devices, while device-bound passkeys can be stored in Microsoft Authenticator, Windows, or a physical FIDO2 security key. Businesses therefore do not have to choose one universal piece of hardware for every employee. The appropriate approach can vary by role, device ownership, administrative privilege, regulatory requirements, and how the organization manages endpoints.
The good news is you can start now, there is no reason to wait until January 2027 to deal with this. Microsoft already supports passkeys in Entra ID, including Entra ID Free, and organizations can begin enabling them, registering users, testing applications, and building recovery procedures today.
Starting early also gives your IT provider a chance to find the exceptions before they become emergencies. An employee with an unusual mobile device, an executive traveling internationally, an administrator with elevated privileges, or a legacy business process that depends on telephone authentication is much easier to deal with months before a mandatory cutoff.
Step 1: Find out who is still using SMS or voice
Before changing authentication policies, determine which Entra users are actually dependent on SMS or voice. Microsoft recommends identifying these users first so that organizations can target their migration rather than blindly changing authentication settings tenant-wide.
This assessment should also distinguish between users who merely have a phone number registered and users who genuinely depend on phone authentication. Someone who already uses Windows Hello or a FIDO2 credential may require little intervention, while an employee whose only usable second factor is a text message needs attention.
Step 2: Enable passkeys in Microsoft Entra
Administrators can configure passkeys under the Authentication Methods policies in the Microsoft Entra admin center. Microsoft’s current deployment model uses passkey profiles, which allow administrators to define permitted passkey types, restrictions, attestation requirements, and the groups that should receive the policy.
A controlled pilot is usually preferable to immediately targeting every employee. Start with IT personnel and a small group of cooperative users, confirm the registration and sign-in experience on the devices your organization actually uses, and then expand the deployment.
Step 3: Have users register their passkeys
Users can register passkeys through Microsoft’s Security Info experience once their organization has enabled the appropriate authentication method. Depending on the organization’s configuration, that passkey can be stored in Microsoft Authenticator, on a Windows device, in a supported synced credential provider, or on a physical FIDO2 security key.
For Microsoft Authenticator, Microsoft supports passkey registration on current iOS and Android versions and recommends registering directly through the Authenticator application when that deployment model is being used. Organizations should test the exact workflow they intend to give employees before distributing instructions company-wide.
Step 4: Plan for account recovery before you enforce anything
Stronger authentication does not eliminate the need for recovery procedures. Employees replace phones, laptops fail, security keys disappear, and administrators eventually have to help someone who no longer possesses the credential they normally use.
Microsoft Entra supports Temporary Access Pass, or TAP, specifically to help users bootstrap passwordless authentication methods or recover when a strong authentication method is unavailable. A TAP can be time limited and configured for controlled onboarding or recovery scenarios.
Your IT team should understand this process before passkeys become mandatory. Locking down authentication without establishing a recovery workflow is an excellent way to turn a security improvement into an avoidable Monday-morning support emergency.
Step 5: Protect administrators more aggressively than ordinary users
Administrative accounts deserve stronger requirements because compromise of an administrator can affect the entire Microsoft 365 environment. Global Administrators and other privileged roles should ideally have more than one phishing-resistant credential available so that the loss of a single phone, laptop, or security key does not create an administrative lockout. For privileged users, physical FIDO2 security keys are still worth serious consideration. Microsoft specifically identifies them as a strong option for elevated users and regulated environments because the private credential remains on the physical authenticator.
So, what should your business be doing now? February 2027 may sound comfortably far away, but authentication changes are much easier to deploy gradually than during a deadline-driven migration. Businesses should use the remaining time to turn passkeys into an ordinary part of their Microsoft 365 environment rather than something employees first encounter when their old MFA method stops working.
A sensible preparation plan includes:
Audit your current authentication methods now. Identify employees who still depend on SMS or voice and pay particular attention to executives, administrators, remote employees, and users with unusual device requirements.
Enable passkeys and run a pilot deployment. Test Microsoft Authenticator, Windows-based passkeys, synced passkeys, and FIDO2 security keys where appropriate rather than assuming one method is ideal for every employee.
Establish a recovery process. Document how your IT team will use methods such as Temporary Access Pass when an employee loses a registered device or needs to enroll a replacement credential.
Communicate with employees before changing their sign-in experience. A short explanation of why passkeys are being introduced can prevent confusion and reduce help desk calls when registration prompts begin appearing.
Review Conditional Access at the same time. Moving to phishing-resistant credentials creates an opportunity to strengthen access requirements for administrators, remote access, sensitive applications, and other higher-risk scenarios.
Do not wait until January 2027. You want February 1 to be an uneventful date on the calendar because your employees migrated months earlier, not the day your organization discovers which users were still relying entirely on text messages.
Can you keep using SMS? Technically, yes, but Microsoft will no longer provide the underlying SMS or voice delivery service after February 1, 2027. Organizations with a documented business, regulatory, or operational requirement will be able to select a supported telecommunications provider through Microsoft’s Security Store and route authentication through that provider.
Microsoft says provider information will become available beginning September 18, 2026, with customer configuration scheduled to become available beginning October 30, 2026. For most small and midsize businesses, however, moving users to passkeys is likely to be both simpler and more aligned with Microsoft’s long-term authentication strategy. You should not wait until February 2027 to move on this. Microsoft’s retirement of native SMS and voice authentication is another signal that traditional MFA is evolving. Having MFA enabled is no longer the finish line because organizations now have to consider whether the authentication method itself can withstand modern phishing, session theft, social engineering, and identity attacks.
The businesses that start preparing now have plenty of time to audit their users, deploy passkeys, test recovery procedures, and address exceptions without disrupting employees. The businesses that ignore the change until early 2027 may instead discover their authentication dependencies when Microsoft starts blocking the workflow they have relied on for years.
Valley Techlogic can help your organization review its Microsoft 365 and Entra authentication environment, identify users who still depend on SMS or voice verification, deploy passkeys, strengthen Conditional Access policies, and create a practical recovery process before the February 2027 deadline. The goal is not simply to satisfy another Microsoft platform change, but to leave your organization with an authentication system that is substantially harder for attackers to defeat. Learn more today with a consultation.
Shadow IT used to mean an employee installing Dropbox, signing up for a project management platform, or using an unapproved messaging app without telling IT. Generative AI has made the problem much bigger. Today, an employee can open a browser, create an account with an AI service, paste in company information, and start using it for research, writing, analysis, customer support, coding, or decision-making within minutes.
They may genuinely be trying to work faster. But without proper oversight, those tools can create security risks, produce unreliable answers, and sometimes make employees less productive instead of more productive. For businesses adopting AI, the question is no longer simply whether employees are using it. The question is whether you know which AI tools they are using, what information they are giving those tools, and whether the answers coming back can actually be trusted.
Traditional shadow IT usually required someone to download software or connect a new service to a company system, AI often requires nothing more than a website. Employees can access dozens of AI assistants, writing tools, meeting transcription services, browser extensions, coding assistants, document analyzers, and automated research platforms without involving management or IT.
That creates two major problems:
The business may have no visibility into where its data is going. Employees might paste contracts, financial information, customer records, source code, internal emails, meeting notes, or strategic plans into services that have never been reviewed.
Employees may trust AI-generated answers more than they should. An answer that sounds polished and authoritative can still be incomplete, outdated, misleading, or completely wrong.
Neither problem necessarily comes from malicious employees. In most cases, employees are simply trying to get their jobs done. That is exactly why businesses need a strategy for AI rather than pretending employees will not use it. Consider how people actually use AI, someone receives a long customer email and asks an AI assistant to summarize it or someone uploads a spreadsheet because they want help understanding the numbers.
A salesperson pastes notes from a confidential meeting into an AI tool and asks it to draft a proposal. A developer submits proprietary source code to an AI assistant to troubleshoot an error. An employee uploads a contract and asks, “What should I be worried about?” Each action may seem harmless in isolation, collectively, however, they can expose some of the most sensitive information your company possesses.
Depending on the service, account type, configuration, and contractual terms, submitted information may be retained, logged, processed by additional systems, or handled in ways that do not satisfy your organization’s privacy, compliance, or contractual requirements. Even if the provider itself has strong security practices, your company still needs to know what information employees are authorized to disclose to it. A secure AI platform cannot protect your business from an employee sharing information they were never supposed to provide in the first place.
Bad AI answers can also be a productivity killer. Security gets most of the attention around shadow AI, but bad answers can be just as costly. AI is remarkably good at generating plausible responses. Unfortunately, plausible and correct are not the same thing. An employee might spend fifteen minutes asking an AI assistant how to solve a problem, receive a confident answer, follow the instructions, discover they do not work, and then spend another hour troubleshooting the problems created by the original advice.
They’re not saving any time by troubleshooting the problem with AI, they’re creating an extremely sophisticated way to waste an afternoon. The problem becomes more serious when AI-generated information makes its way into customer communications, financial decisions, technical configurations, legal documents, or management reports.
Two risks deserve particular attention:
AI can confidently invent information. Fabricated statistics, nonexistent software settings, incorrect regulations, made-up citations, and inaccurate technical instructions can all look legitimate.
Employees can lose time validating low-quality output. If every answer requires extensive fact-checking, correcting, and rewriting, the organization may actually be adding another step to the workflow rather than removing one.
The goal of AI adoption should be measurable productivity improvement, not simply maximizing how often employees interact with AI. This is where many businesses make a mistake, they either allow everything or ban everything. Neither approach works particularly well, a blanket ban often pushes AI usage underground. Employees who believe a tool makes them dramatically more productive may simply use it without telling anyone. Unlimited access creates the opposite problem. Employees can experiment with services that have never been evaluated for security, privacy, reliability, or business suitability. A better strategy is managed adoption.
Your organization can approve specific AI platforms, define which types of data can be used with them, configure business-grade security controls where available, and train employees on appropriate use. Employees get useful tools, management gets visibility and IT gets the ability to put guardrails around everything.
You cannot manage technology you do not know exists. An effective shadow IT review should therefore combine technical discovery with conversations about how employees actually work.
1. Inventory the Applications Employees Are Using
Start by identifying the software and online services being accessed across the organization. Review endpoint software inventories, browser extensions, SaaS applications, identity provider sign-ins, expense reports, corporate card transactions, and recurring subscriptions. Pay particular attention to AI assistants, transcription platforms, document-processing tools, browser-based productivity applications, and services employees may have purchased individually. The goal is not immediately to block everything unfamiliar but to create visibility into how and when tools are being used.
2. Ask Employees How They Are Using AI
Technical tools will not reveal everything, you’ll need to actually talk to your employees. Ask which AI platforms they use, what tasks they use them for, what information they typically provide, and which tools genuinely save them time. You may discover highly effective workflows worth formally adopting, you may also discover someone casually uploading confidential customer documents into a consumer AI service. An audit should find both.
3. Classify Your Business Information
Employees cannot follow data-handling rules that have never been defined. Create understandable categories for information such as public, internal, confidential, and highly restricted. Then define what employees may provide to external AI systems. A marketing employee asking an AI assistant to brainstorm headlines using information already published on your website is very different from an employee uploading payroll records, your policy should make that distinction obvious.
4. Approve a Small Set of Business AI Platforms
Give employees a sanctioned alternative, select AI platforms that meet your organization’s security, privacy, identity, and administrative requirements. Where possible, use business or enterprise accounts rather than unmanaged personal accounts. Centralized platforms can also make it easier to implement authentication requirements, access controls, auditing, data protections, and employee offboarding. If the approved platform is useful and easy to access, employees have much less reason to create their own solution.
5. Establish an AI Acceptable Use Policy and Review It Regularly
AI governance should not be a document that gets written once and forgotten. Define what employees can use AI for, which services are approved, what information cannot be submitted, when AI-generated information must be verified, and who employees should contact before adopting a new tool. Then revisit the policy as your business and the technology change. AI products are evolving too quickly for a policy written today to remain untouched for the next five years.
The Goal Is Not to Stop Employees From Using AI
Generative AI can absolutely improve productivity. It can help employees summarize information, draft documents, analyze data, troubleshoot problems, automate repetitive tasks, research unfamiliar subjects, and get through routine administrative work faster, but AI works best when it is treated as a business tool rather than a free website everyone can use however they want. Businesses already manage email, cloud storage, endpoint security, financial systems, and customer databases, AI deserves the same attention.
The organizations that benefit most from AI will probably not be the ones that give employees unrestricted access to every new tool, they will be the ones that figure out where AI genuinely improves the work, provide employees with secure ways to use it, and establish clear boundaries around the information that should never leave the business. Shadow IT thrives when employees have a problem and IT has not provided an approved solution.
Find those problems first, give employees better options, and AI can become a productivity tool instead of another source of risk. Valley Techlogic is already helping clients navigate their AI strategies and stamp out unnecessary risks found when employees are left to their own devices in finding AI solutions that assist with their workload. We can help you develop a plan that will both increase productivity while keeping data security in mind, and can recommend tools that are industry tested and proven. Learn more today with a consultation.
Anthropic dropped a surprisingly consequential announcement this week: text generated by supported Claude models will contain an invisible, machine-readable watermark. Not just images, not just obvious AI-generated media, now text itself will be easily identifiable as AI generated. Also, importantly for developers, that even includes text generated through products such as Claude Code.
Predictably, portions of the internet reacted as though Anthropic had announced that every Claude response would arrive with a scarlet letter attached to it. The reality is more complicated, Anthropic is not doing this simply because it woke up one morning and decided people should be able to identify Claude-written emails, blog posts and Python functions. The change is closely tied to the European Union’s AI Act, specifically the transparency requirements that became applicable on August 2, 2026. Those rules require providers of generative AI systems to make artificially generated or manipulated content detectable in a machine-readable form.
Anthropic has signed the EU AI Act’s Article 50 Code of Practice on Transparency of AI-Generated Content and is implementing the marking system as part of that commitment. In other words, this is as much a regulatory story as it is a technology story. So, what is Anthropic actually doing? Anthropic says supported Claude models will use two different mechanisms.
Generated text will contain an “imperceptible watermark” embedded directly into the text itself. Generated files such as PNG, JPG and SVG files can additionally carry signed provenance metadata using C2PA, the Coalition for Content Provenance and Authenticity standard.
The text watermark is the interesting part. Anthropic says it is part of the generated text itself, which means the identifying signal can survive copying and pasting and may survive some subsequent editing. It is also implemented at the model level rather than being something added only by the Claude website.
That means supported models can produce marked output regardless of whether you are accessing them through Claude, the Anthropic API, Claude Code, Claude Cowork, Claude Tag, AWS, Google Cloud or Microsoft Foundry. Anthropic says the system will apply worldwide, not just to customers located inside the European Union. The EU passed the rule, but users everywhere get the implementation.
Anthropic’s current rollout policy is that Claude models launched in the EU on or after August 2, 2026 support machine-readable marking from launch. Models released before August 2 are covered by a transition period, and Anthropic says it is working to add marking support to those older versions as well.
So, if your response to this news is, “I’ll just keep using an older Claude model,” enjoy that workaround while it lasts and yes, this new rule will apply to code. This is actually where the discussion gets considerably more interesting. Claude Code is explicitly included among the products covered by Anthropic’s marking system, and Anthropic says embedded watermarks apply to generated text from supported models. Code, conveniently enough, is also text.
That raises questions that are very different from the familiar debate about students submitting AI-generated essays or people publishing machine-written LinkedIn thought leadership about how drinking coffee taught them seven lessons about enterprise leadership.
Increasingly, developers for example use AI as part of normal software development. Claude might generate an entire function. It might refactor an existing function. It might replace five lines. It might fix a bug. It might add comments. It might translate PowerShell into Python. It might simply suggest a more efficient conditional statement. At what point does Claude-generated code become Claude-processed code?
Anthropic itself acknowledges exactly this problem with text generally. A detected watermark does not prove that Claude originally authored the material. Someone may have written something themselves and then asked Claude to proofread, translate, summarize or transform it.
The resulting output can still carry a Claude watermark. There may not be a distinction between “Claude processed this” and “Claude wrote this”. Some of the objections are predictable from those who already, or aspired, to use AI ubiquitously in their creative process with limited input beyond prompting. Other concerns are simply related to using AI as an assistant with limited input into the creative process (such as grammatical corrections or checking for bugs).
The controversy largely falls into a few categories:
Authorship. If someone writes a document and uses Claude for editing, the resulting text may still contain the watermark. A detector therefore cannot automatically establish who actually wrote the underlying material.
Code ownership and copyright. Developers are asking how machine-readable evidence of AI involvement might someday interact with software copyright disputes, licensing, corporate intellectual property policies and provenance requirements.
Privacy. Some critics dislike the idea that text can carry an invisible indication of having passed through a particular company’s system.
Detection asymmetry. Anthropic has not yet published complete technical details about the text watermark. The company says it plans to provide detection mechanisms for users and third parties, including a free API for checking Claude watermarks.
That last point has produced a particularly intense reaction. People are understandably uncomfortable with the idea of a vendor invisibly marking their output while being the only party initially capable of reliably identifying that mark. Anthropic appears to recognize the problem. Its documentation says it intends to enable users and third parties to detect the markings themselves and will publish additional technical documentation.
Until that documentation exists, though, there are unanswered technical questions. We do not yet know enough about the implementation to confidently say how resistant the text watermark will be to reformatting, linting, refactoring, partial rewriting, token substitution or other transformations. We do know that the implementation involves pattern matching.
When a human writes it’s naturally random, when AI writes it’s much more predictable. It’s this predictability that will be used as a “watermark”. Where you may not consciously notice for example, that every 5th sentence starts with a word that begins with a capital “T”, AI can. It’s in the pattern matching component that will form digital watermark will form.
Implementation is probably the most important part of the announcement, and one that will inevitably disappear as AI detection products begin adding giant green and red “CLAUDE DETECTED” buttons to their interfaces. Anthropic explicitly warns that its marking system is not conclusive proof of authorship. A positive detection means the content may have been processed by Claude. It does not necessarily mean Claude created the underlying ideas, original language or data. Likewise, failing to detect a watermark does not prove that something was written by a human.
Anthropic lists several reasons a mark might disappear or become undetectable. Text can be heavily edited, paraphrased, translated or mixed with other writing. Very short passages may not contain enough information for a reliable signal. File metadata can disappear during format conversion, screenshots or re-saving. That makes this fundamentally different from a cryptographic certificate saying, “Claude wrote this exact document.”
We are rapidly approaching a world in which enormous amounts of text, software, imagery, music and video are machine generated or machine assisted. Knowing something about where that material came from has value. It could help content platforms distinguish synthetic media. It could give researchers better information about training datasets. It could make certain types of fraud easier to investigate. It could improve provenance tracking inside enterprises that increasingly have humans and AI systems collaboratively producing documents and software.
There is even a longer-term AI problem here. As synthetic content floods the internet, future models risk consuming increasing quantities of previous models’ output during training. Reliable provenance systems could theoretically help developers identify and filter some of that synthetic data. Several technologists have pointed to exactly this potential benefit amid the backlash. The problem is not necessarily that provenance exists, the problem is what people eventually decide provenance means.
There is a danger in bad interpretation, however. We already spent several years watching unreliable “AI detectors” accuse students of cheating because their sentence structure looked statistically suspicious. A genuine provider-generated watermark is much stronger evidence that an AI system touched something, but even Anthropic is explicitly saying that this does not establish authorship. That nuance needs to survive contact with HR departments, universities, automated compliance platforms and procurement policies.
Anthropic will almost certainly not be the last major AI company dealing with this problem. The European Commission says Article 50’s transparency obligations apply from August 2, 2026, and the Code of Practice specifically calls for AI-generated audio, images, video and text to be marked in machine-readable formats using techniques that are effective, interoperable, robust and reliable where technically feasible.
Anthropic is therefore an early and very visible example of a broader shift. The internet spent the first few years of the generative AI boom arguing about whether AI-generated content could be detected. We are now entering the next phase, where regulators are increasingly asking whether AI companies should deliberately make it detectable, those are very different questions.
For developers, writers, businesses and anyone else who routinely uses LLMs as part of their workflow, the most important consequence may not be that Claude is watermarking its output. It may be that AI provenance is about to become a normal part of the creation process. Whether that turns into a genuinely useful transparency mechanism or the world’s largest automated “gotcha” system will depend considerably less on the watermark itself than on what everyone else decides to do with it.
Digital watermark or not, AI is here to stay and we’ve seen our clients implement AI solutions directly into their business with Valley Techlogic’s guidance. How you implement AI is just as important as how you will use it day to day, and questions surrounding data security and privacy, access controls, retention, compliance, and governance should be answered before these tools become embedded in your organization’s workflows. If you would like to learn more about AI readiness and how Valley Techlogic can help your business with its AI strategy, schedule a free consultation today to get started.
Password managers have become one of the most important cybersecurity tools available to individuals and businesses. They make it practical to create a unique, complex password for every account without having to memorize hundreds of credentials.
But because a password manager stores so much sensitive information, it is reasonable to ask an important question:
Can password managers be hacked? The honest answer is yes. Any software, device, or online service can potentially be attacked. However, that does not mean using a password manager is more dangerous than managing passwords yourself.
For most people and businesses, the opposite is true. A reputable password manager dramatically reduces the risks created by weak passwords, password reuse, spreadsheets, browser notes, sticky notes, and credentials shared through email or text messages.
How does a password manager protection your passwords? A properly designed password manager encrypts your vault before sending it to the provider’s servers. The provider should not possess the information needed to decrypt your stored passwords.
This approach is often described as zero-knowledge encryption. Your vault can be synchronized between devices, but its contents remain encrypted until you unlock it with your master password or another approved authentication method.
That does not make a password manager invincible. An attacker could still attempt to:
Steal your master password through phishing, malware, or social engineering
Access an already unlocked computer, phone, or browser session
Exploit a vulnerability in the password manager’s application or browser extension
Compromise the provider’s infrastructure and steal encrypted vault data
Trick an employee into approving a fraudulent multifactor authentication request
The biggest practical risk is usually not someone breaking the encryption itself. It is an attacker stealing the user’s master password, compromising their device, or convincing them to approve access. Is it still safer to use a password manager?Yes, since people tend to reuse the same password across multiple websites or make minor variations that are easy for attackers to predict when they don’t use one. When one website is breached, criminals can test the stolen password against email, banking, Microsoft 365, social media, and other services.
A password manager allows every account to have a long, random, and completely unique password. If one website is compromised, the stolen password cannot be reused to access your other accounts. Password managers also makes it easier to identify reused passwords, detect known compromised credentials, securely share business accounts, and revoke access when an employee leaves.
The goal is not to eliminate every possible risk, there is no product that can promise that. The goal is to replace unsafe password habits with a system that is considerably harder to compromise.
So, what are our password manager recommendations? Valley Techlogic recommends Bitwarden, 1Password, and Proton Pass. We feel it’s notable that of August 2026, none of these providers has publicly reported a breach that exposed customers’ decrypted password vaults. All three use strong encryption and have undergone independent security reviews. The best choice depends on your budget, technical requirements, privacy preferences, and the people who will be using it.
1. Bitwarden
Bitwarden is an established open-source password manager with options for individuals, families, and businesses. Its source code can be inspected publicly, and the company conducts recurring third-party security audits, source-code assessments, and penetration testing.
Pros
Open-source applications and server components provide a high degree of transparency
Strong free plan and reasonably priced paid options
Available on major browsers, computers, and mobile devices
Supports business collections, secure credential sharing, and administrative controls
Can be self-hosted by organizations with the expertise to maintain it securely
Includes reports for weak, reused, and exposed passwords
Cons
The interface is functional but may feel less polished than 1Password
Some administrative and reporting features require a paid business plan
Self-hosting adds significant maintenance and security responsibility
New or less technical users may need additional training during deployment
Best for: Cost-conscious businesses, technical teams, open-source advocates, and organizations that want flexible deployment options.
2. 1Password
1Password is known for its polished interface and approachable user experience. In addition to your account password, it uses a locally generated Secret Key that strengthens the encryption of your vault. The company states that it has not experienced a breach of its password-management service. During the 2023 Okta support-system incident, 1Password detected suspicious activity involving its employee-facing Okta environment but reported that no user data or sensitive systems were compromised.
Pros
Excellent interface that is easy for nontechnical users to understand
Secret Key provides additional protection beyond the account password
Strong family and business-sharing features
Useful administrative controls for onboarding and offboarding employees
Travel Mode can temporarily remove selected vaults from a device
Watchtower identifies compromised websites, vulnerable passwords, and other security concerns
Cons
No permanent free plan for general password-manager use
Typically costs more than Bitwarden
The complete product is not open source
Users must protect both their account password and Emergency Kit containing the Secret Key
Best for: Businesses that prioritize ease of use, employee adoption, polished administration, and a low-friction user experience.
3. Proton Pass
Proton Pass is part of Proton’s privacy-focused ecosystem, which also includes Proton Mail, Proton VPN, Proton Calendar, and Proton Drive. Proton Pass is open source, uses end-to-end encryption, and has undergone independent security testing by Cure53. Its audit covered the mobile applications, browser extensions, and API.
Pros
Open-source applications with publicly available security information
Strong privacy focus and end-to-end encryption
Clean, modern interface
Integrates well with other Proton services
Supports email aliases that can reduce spam and limit account tracking
Competitive free and paid options
Cons
Newer than Bitwarden and 1Password, with a shorter operational history
Business-management features may not be as mature as more established competitors
Organizations already standardized on another email or identity ecosystem may receive less benefit from Proton integration
Some advanced features require a paid Proton subscription
Best for: Privacy-conscious individuals, Proton customers, small businesses, and users who value encrypted email aliases alongside password management.
You may be wondering which of these three you should choose for your business. For many businesses, 1Password offers the smoothest user experience and may require the least training. Bitwarden is an excellent choice for businesses that want strong security, open-source transparency, and competitive pricing. Proton Pass is particularly attractive for privacy-focused users and organizations that already use, or plan to use, other Proton services.
The most important factor is not choosing the theoretically perfect password manager. It is selecting a reputable product that your team will actually use consistently.
So how can you use a password manager safely? A password manager should be part of a broader account-security strategy. Simply installing one is not enough. Use a long and unique master password that has never been used anywhere else. A memorable passphrase made from several unrelated words is generally easier to remember and more difficult to guess than a short, complicated password.
Enable multifactor authentication on the password-manager account. Whenever possible, use a passkey, hardware security key, or authenticator application instead of SMS. Keep computers, phones, browsers, and password-manager applications updated. Avoid installing unnecessary browser extensions, and use reputable endpoint-security software to reduce the risk of credential-stealing malware.
Businesses should also establish procedures for securely sharing credentials, removing former employees, reviewing administrative access, and recovering accounts when an authorized user loses access. Password managers can be attacked, just like email providers, banks, cloud platforms, and other online services. That is not a good reason to avoid them.
A reputable password manager stores your credentials in an encrypted vault and makes it possible to use a different random password for every account. This protects you from one of the most common causes of account compromise: reused credentials.
Bitwarden, 1Password, and Proton Pass are all strong options with different advantages. None can guarantee that an attack will never occur, but each offers a substantially safer approach than reused passwords, shared spreadsheets, browser notes, or credentials passed between employees through email.
Valley Techlogic can help your organization select, configure, and deploy a password manager that fits your staff, security requirements, and budget. We can also help establish secure onboarding, offboarding, multifactor authentication, and credential-sharing procedures so the password manager becomes part of a complete security program rather than another unused application. Learn more today with a consultation.
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Cookie Preferences
Manage your cookie preferences below:
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
_uetvid
1 Year
KievRPSAuth
Helps to authenticate you when you sign in with your Microsoft account.
5 years
ANON
Contains the A, a unique identifier derived from your Microsoft account, which is used for advertising, personalization, and operational purposes. It is also used to preserve your choice to opt out of interest-based advertising from Microsoft if you have chosen to associate the opt-out with your Microsoft account.
1 year
MSFPC
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
_uetsid
This cookie is used by Bing to determine what ads should be shown that may be relevant to the end user perusing the site.
30 minutes
_uetvid
This is a cookie utilised by Microsoft Bing Ads and is a tracking cookie. It allows us to engage with a user that has previously visited our website.
16 days
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
CC
Contains a country code as determined from your IP address.
1 year
PPAuth
Helps to authenticate you when you sign in with your Microsoft account.
5 years
MSPAuth
Helps to authenticate you when you sign in with your Microsoft account.
5 years
MSNRPSAuth
Helps to authenticate you when you sign in with your Microsoft account.
5 years
brcap
Microsoft Microsoft Online Authentication Cookie
1 year
x-ms-gateway-slice
Identifies a gateway for load balancing.
End of session (browser)
ToptOut
Records your decision not to receive interest-based advertising delivered by Microsoft.
1 year
ACH01
Maintains information about which ad and where the user clicked on the ad.
End of session (browser)
AADSSO
Microsoft Microsoft Online Authentication Cookie
End of session (browser)
MR
Used to collect information for analytics purposes.
6 months
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
MUIDB
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
MC1
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
MS0
Identifies a specific session.
End of session (browser)
_UR
This cookie is used by the Bing advertising network for advertising tracking purposes.
1 year
NAP
Contains an encrypted version of your country, postal code, age, gender, language and occupation, if known, based on your Microsoft account profile.
1 year
MH
Appears on co-branded sites where Microsoft is partnering with an advertiser. This cookie identifies the advertiser, so the right ad is selected.
End of session (browser)
childinfo
Contains information that Microsoft account uses within its pages in relation to child accounts.
5 years
kcdob
Contains information that Microsoft account uses within its pages in relation to child accounts.
5 years
kcrelid
Contains information that Microsoft account uses within its pages in relation to child accounts.
5 years
kcru
Contains information that Microsoft account uses within its pages in relation to child accounts.
5 years
pcfm
Contains information that Microsoft account uses within its pages in relation to child accounts.
5 years
_HPVN
Analysis service that connects data from the Bing advertising network with actions performed on the website.
1 year
MC0
Detects whether cookies are enabled in the browser.
End of session (browser)
_RwBf
This cookie helps us to track the effectiveness of advertising campaigns on the Bing advertising network.
1 year
MSPProf
Helps to authenticate you when you sign in with your Microsoft account.
5 years
SRM_B
Collected user data is specifically adapted to the user or device. The usercan also be followed outside of the loaded website, creating a picture of the visitor's behavior.
1 year
WLSSC
Helps to authenticate you when you sign in with your Microsoft account.
5 years
MSPTC
This cookie registers data on the visitor. The information is used to optimize advertisement relevance.
1 year
ACLUSR
This cookie is used for advertisement tracking purposes.
1 year
ACL
This cookie is used for advertisement tracking purposes.
3 months
OIDR
This cookie is used by the Bing advertising network for advertising tracking purposes.
3 months
OID
This cookie is used by the Bing advertising network for advertising tracking purposes.
3 months
OIDI
This cookie is used by the Bing advertising network for advertising tracking purposes.
3 months
BCP
This cookie is used for advertisement tracking purposes.
1 year
BFBUSR
This cookie is used for advertisement tracking purposes.
1 year
BFB
This cookie is used for advertisement tracking purposes.
1 year
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gid
ID used to identify users for 24 hours after last activity
24 hours
_ga_
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga
ID used to identify users
2 years
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
Hotjar is a powerful analytics tool that helps you understand user behavior through heatmaps and session recordings.
Name
Description
Duration
_hjSessionUser_1849187
1 Year
_hjShownFeedbackMessage
This cookie is set when a visitor minimizes or completes Incoming Feedback. This is done so that the Incoming Feedback will load as minimized immediately if they navigate to another page where it is set to show.
365 days
_hjMinimizedTestersWidgets
Hotjar cookie. This cookie is set once a visitor minimizes a Recruit User Testers widget. It is used to ensure that the widget stays minimizes when the visitor navigates through your site.
365 days
_hjDoneTestersWidgets
Hotjar cookie. This cookie is set once a visitor submits their information in the Recruit User Testers widget. It is used to ensure that the same form does not re-appear if it has already been filled in.
365 days
_hjMinimizedPolls
Hotjar cookie. This cookie is set once a visitor minimizes a Feedback Poll widget. It is used to ensure that the widget stays minimizes when the visitor navigates through your site.
365 days
_hjDonePolls
Hotjar cookie. This cookie is set once a visitor completes a poll using the Feedback Poll widget. It is used to ensure that the same poll does not re-appear if it has already been filled in.
365 days
_hjClosedSurveyInvites
Hotjar cookie. This cookie is set once a visitor interacts with a Survey invitation modal popup. It is used to ensure that the same invite does not re-appear if it has already been shown.
365 days
_hjCookieTest
This cookie checks to see if the Hotjar Tracking Code can use cookies. If it can, a value of 1 is set.
Session
_hjUserAttributesHash
User Attributes sent through the Hotjar Identify API are cached for the duration of the session in order to know when an attribute has changed and needs to be updated.
session
_hjCachedUserAttributes
This cookie stores User Attributes which are sent through the Hotjar Identify API, whenever the user is not in the sample. These attributes will only be saved if the user interacts with a Hotjar Feedback tool.
session
_hjLocalStorageTest
This cookie is used to check if the Hotjar Tracking Script can use local storage. If it can, a value of 1 is set in this cookie. The data stored in_hjLocalStorageTest has no expiration time, but it is deleted immediately after creating it so the expected storage time is under 100ms.
-
_hjid
Hotjar cookie. This cookie is set when the customer first lands on a page with the Hotjar script. It is used to persist the random user ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
365 days
hj_visitor
hotjar uses cookies to enhance the user’s experience on our website, for example to complete forms, navigating the site, and identify returning users and offer related content. Users can control the use of cookies at the individual browser level.
Session
_hjIncludedInSample
Hotjar cookie. This session cookie is set to let Hotjar know whether that visitor is included in the sample which is used to generate funnels.
365 days
_hjHasCachedUserAttributes
This cookie sets when a user first lands on a page. Persists the Hotjar User ID which is unique to that site. Hotjar does not track users across different sites. Ensures data from subsequent visits to the same site are attributed to the same user ID.
365 days
_hjSessionRejected
If present, this cookie will be set to 1 for the duration of a user’s session, if Hotjar rejected the session from connecting to our WebSocket due to server overload. This cookie is only applied in extremely rare situations to prevent severe performance issues.
session
_hjIncludedInSessionSample
This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's daily session limit
30 minutes
_hjSession_
A cookie that holds the current session data. This ensues that subsequent requests within the session window will be attributed to the same Hotjar session.
30 minutes
_hjSessionUser_
Hotjar cookie that is set when a user first lands on a page with the Hotjar script. It is used to persist the Hotjar User ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
365 days
_hjSessionTooLarge
Causes Hotjar to stop collecting data if a session becomes too large. This is determined automatically by a signal from the WebSocket server if the session size exceeds the limit.
session
_hjSessionResumed
A cookie that is set when a session/recording is reconnected to Hotjar servers after a break in connection.
session
hjViewportId
This cookie stores user viewport details such as size and dimensions.
Session
_hjSessionStorageTest
This cookie checks if the Hotjar Tracking Code can use Session Storage. If it can, a value of 1 is set.
Session
_hjTLDTest
When the Hotjar script executes we try to determine the most generic cookie path we should use, instead of the page hostname. This is done so that cookies can be shared across subdomains (where applicable). To determine this, we try to store the _hjTLDTest cookie for different URL substring alternatives until it fails. After this check, the cookie is removed.
session
_hjIncludedInPageviewSample
This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's page view limit.
30 minutes
_hjFirstSeen
The cookie is set so Hotjar can track the beginning of the user's journey for a total session count. It does not contain any identifiable information.
30 minutes
_hjAbsoluteSessionInProgress
The cookie is set so Hotjar can track the beginning of the user's journey for a total session count. It does not contain any identifiable information.
30 minutes
_hjptid
This cookie is set for logged in users of Hotjar, who have Admin Team Member permissions. It is used during pricing experiments to show the Admin consistent pricing across the site.
session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utma
ID used to identify users and sessions
2 years after last activity
Hotjar is a powerful analytics tool that helps you understand user behavior through heatmaps and session recordings.
Name
Description
Duration
_hjShownFeedbackMessage
This cookie is set when a visitor minimizes or completes Incoming Feedback. This is done so that the Incoming Feedback will load as minimized immediately if they navigate to another page where it is set to show.
365 days
_hjMinimizedTestersWidgets
Hotjar cookie. This cookie is set once a visitor minimizes a Recruit User Testers widget. It is used to ensure that the widget stays minimizes when the visitor navigates through your site.
365 days
_hjDoneTestersWidgets
Hotjar cookie. This cookie is set once a visitor submits their information in the Recruit User Testers widget. It is used to ensure that the same form does not re-appear if it has already been filled in.
365 days
_hjMinimizedPolls
Hotjar cookie. This cookie is set once a visitor minimizes a Feedback Poll widget. It is used to ensure that the widget stays minimizes when the visitor navigates through your site.
365 days
_hjDonePolls
Hotjar cookie. This cookie is set once a visitor completes a poll using the Feedback Poll widget. It is used to ensure that the same poll does not re-appear if it has already been filled in.
365 days
_hjClosedSurveyInvites
Hotjar cookie. This cookie is set once a visitor interacts with a Survey invitation modal popup. It is used to ensure that the same invite does not re-appear if it has already been shown.
365 days
_hjIncludedInSample
Hotjar cookie. This session cookie is set to let Hotjar know whether that visitor is included in the sample which is used to generate funnels.
365 days
hj_visitor
hotjar uses cookies to enhance the user’s experience on our website, for example to complete forms, navigating the site, and identify returning users and offer related content. Users can control the use of cookies at the individual browser level.
Session
_hjid
Hotjar cookie. This cookie is set when the customer first lands on a page with the Hotjar script. It is used to persist the random user ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
365 days
_hjHasCachedUserAttributes
This cookie sets when a user first lands on a page. Persists the Hotjar User ID which is unique to that site. Hotjar does not track users across different sites. Ensures data from subsequent visits to the same site are attributed to the same user ID.
365 days
_hjSessionResumed
A cookie that is set when a session/recording is reconnected to Hotjar servers after a break in connection.
session
hjViewportId
This cookie stores user viewport details such as size and dimensions.
Session
_hjSessionStorageTest
This cookie checks if the Hotjar Tracking Code can use Session Storage. If it can, a value of 1 is set.
Session
_hjTLDTest
When the Hotjar script executes we try to determine the most generic cookie path we should use, instead of the page hostname. This is done so that cookies can be shared across subdomains (where applicable). To determine this, we try to store the _hjTLDTest cookie for different URL substring alternatives until it fails. After this check, the cookie is removed.
session
_hjCookieTest
This cookie checks to see if the Hotjar Tracking Code can use cookies. If it can, a value of 1 is set.
Session
_hjUserAttributesHash
User Attributes sent through the Hotjar Identify API are cached for the duration of the session in order to know when an attribute has changed and needs to be updated.
session
_hjCachedUserAttributes
This cookie stores User Attributes which are sent through the Hotjar Identify API, whenever the user is not in the sample. These attributes will only be saved if the user interacts with a Hotjar Feedback tool.
session
_hjLocalStorageTest
This cookie is used to check if the Hotjar Tracking Script can use local storage. If it can, a value of 1 is set in this cookie. The data stored in_hjLocalStorageTest has no expiration time, but it is deleted immediately after creating it so the expected storage time is under 100ms.
-
_hjSessionTooLarge
Causes Hotjar to stop collecting data if a session becomes too large. This is determined automatically by a signal from the WebSocket server if the session size exceeds the limit.
session
_hjSessionRejected
If present, this cookie will be set to 1 for the duration of a user’s session, if Hotjar rejected the session from connecting to our WebSocket due to server overload. This cookie is only applied in extremely rare situations to prevent severe performance issues.
session
_hjSessionUser_
Hotjar cookie that is set when a user first lands on a page with the Hotjar script. It is used to persist the Hotjar User ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
365 days
_hjSession_
A cookie that holds the current session data. This ensues that subsequent requests within the session window will be attributed to the same Hotjar session.
30 minutes
_hjIncludedInSessionSample
This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's daily session limit
30 minutes
_hjIncludedInPageviewSample
This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's page view limit.
30 minutes
_hjFirstSeen
The cookie is set so Hotjar can track the beginning of the user's journey for a total session count. It does not contain any identifiable information.
30 minutes
_hjAbsoluteSessionInProgress
The cookie is set so Hotjar can track the beginning of the user's journey for a total session count. It does not contain any identifiable information.
30 minutes
_hjptid
This cookie is set for logged in users of Hotjar, who have Admin Team Member permissions. It is used during pricing experiments to show the Admin consistent pricing across the site.
session
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Beamer is a presentation software that enables users to create engaging, interactive slideshows for diverse audiences.
Name
Description
Duration
_BEAMER_USER_ID_DjYMYPMX42643
1 Year
_BEAMER_LAST_UPDATE_DjYMYPMX42643
1 Year
_BEAMER_LAST_POST_SHOWN_DjYMYPMX42643
1 year
_BEAMER_FIRST_VISIT_DjYMYPMX42643
-
_BEAMER_FIRST_VISIT_
Set by Beamer (hotjar.com) to store the date of the user’s first interaction with insights.
3000 days
_BEAMER_USER_ID_
Set by Beamer (hotjar.com) to store an internal ID for a user.
300 days
_BEAMER_DATE_
Set by Beamer (hotjar.com). Stores the latest date in which the feed or page was opened.
300 days
_BEAMER_LAST_POST_SHOWN_
Set by Beamer (hotjar.com). Stores the timestamp for the last time the number of unread posts was updated for the user.
300 days
_BEAMER_FILTER_BY_URL_
This cookie is set by Beamer to store whether to apply URL filtering on the feed
20 minutes
Facebook Pixel is a web analytics service that tracks and reports website traffic.
