The BBC reports that a Google official said the company’s Gemini model reached the open internet and guessed its way into three websites during a security test. The defence is unglamorous: remove guessable credentials, then add a second factor.
Gather what you need before you start
You need an accurate list of the systems your organisation exposes to the internet, administrative access to each of them, and permission to change authentication settings. If you are doing this for an employer, get that permission in writing before you touch anything, because locking colleagues out of a production system is a faster route to trouble than any attacker.
You also need a password manager, either a personal one or a team vault, and somewhere to record what you changed and when. Most of the work below is clerical rather than technical. The difficulty is not knowing what to do; it is knowing what exists. Almost every organisation has at least one login page nobody has thought about for years.
What the reported test does not change is the underlying technique. Guessing credentials is an old attack. The detail worth taking seriously is that an automated system was able to carry it out end to end — find the target, reach it over the network, and try credentials — without a person driving each step. That lowers the cost of doing it at scale, and cost is what has historically kept low-value targets safe.
Inventory every account that faces the internet
Start by writing down every service that accepts a username and password from outside your network. Include the obvious ones — email, remote access, cloud consoles, VPN — and then the ones that get forgotten: the website admin panel, the router or firewall management page, the printer, the building access system, the staging server that was meant to be temporary, the monitoring dashboard, the old ticketing system nobody migrated.
For each, record who owns it, who has an account, and whether it is reachable from the public internet or only from inside. Anything that turns out to be publicly reachable and no longer used should be switched off rather than secured. An unused service with a login page is a liability with no compensating benefit.
Retire shared and default credentials first
Default credentials shipped by a vendor, and passwords shared between several people, are the two categories an automated attacker finds most cheaply. Both are guessable in the strict sense: they appear on public lists, or they follow a pattern derived from the organisation’s name, the product name, or the year.
Work through the inventory and give every person their own account. Where a system genuinely cannot support individual accounts — some older hardware cannot — put the shared credential in a vault, change it, restrict who can read it, and put that system on a list to be replaced. Change every vendor default you find, including on devices that appear to be inert, such as network appliances and cameras.
Generate long passwords instead of choosing them
A password you invented is a password something can model. Use the password manager’s generator, accept whatever it produces, and never type it from memory. Length matters more than symbol variety, and reuse matters more than either: a password used in two places fails in two places.
Prioritise by blast radius rather than by how often you log in. The identity provider, the domain registrar, the cloud account and the email account used for password resets come first, because control of any of them unlocks the rest. Personal accounts that can reset work accounts belong in the same tier, even though they sit outside company policy.
Turn on multi-factor authentication everywhere it exists
Guessing a password becomes much less useful when the password alone is not enough. Enable a second factor on every service in the inventory that supports one. Prefer hardware security keys or passkeys where they are offered, then an authenticator application, and treat text messages as the weakest acceptable option rather than the default.
Enforce it centrally if you can, so that new accounts inherit the requirement instead of relying on individuals to opt in. Store the recovery codes in the vault, not in the same mailbox the second factor is meant to protect. Then test the recovery path once, deliberately, while you still have working access.
Rate-limit and log your authentication endpoints
Automated guessing produces a distinctive pattern: many attempts, often against many accounts, frequently from addresses or networks you have never seen before. Configure lockouts or progressive delays after repeated failures, and make sure failed logins are actually written to a log that someone or something reads.
Set an alert for spikes in failed authentication, for successful logins from unfamiliar locations, and for the first successful login to a dormant account. Restrict administrative interfaces to a VPN or an allowlist so they are not reachable from the open internet at all. A login page that cannot be reached cannot be guessed against.
Extend the same treatment to machine accounts
Service accounts, API keys, deployment tokens and integration credentials are often excluded from password policy, cannot use multi-factor authentication, and never expire. They are also frequently over-privileged, because whoever created them granted broad access to make a deployment work and never narrowed it.
Rotate them, scope each one to the minimum permission it needs, and record where each is used so rotation does not break production. Scan your code repositories for credentials committed by accident, including in old branches and commit history. Revoke anything you find rather than merely deleting the line, because the value remains valid until it is revoked at the source.
Avoid the mistakes people actually make
The most common is treating the inventory as finished. Systems appear continuously, and the one added last week by a team that did not tell you is the one nobody hardened. Repeat the discovery step on a schedule.
The second is securing the front door while leaving a side entrance: enforcing multi-factor authentication on the web interface but leaving the legacy protocol, the API or the mail connector authenticating with a password alone. Attackers, automated or otherwise, use whichever path still works.
The third is a complexity policy that produces predictable passwords. Requirements to include a capital letter and a number, changed every ninety days, reliably generate a family of similar passwords that are easy to derive once one is known.
The fourth is ignoring the password reset flow. If resets depend on an email account or a phone number that is itself weakly protected, the password strength elsewhere is decorative.
The fifth is never testing the alerts. A log nobody reads and an alarm nobody has triggered on purpose are indistinguishable from having neither.
Recognise when this is the wrong approach
This is hygiene, not a security programme. If your realistic concern is a targeted intrusion by a well-resourced group, credential hardening is necessary but nowhere near sufficient, and effort is better spent on segmentation, detection, logging you can actually query, and a tested response plan.
It is also the wrong first move if you are already compromised. Rotating credentials while an intruder holds persistent access can destroy evidence and alert them without removing them. In that situation, containment and investigation come first.
And if you are considering pointing an AI agent at systems yourself to see what it finds, the constraint is legal rather than technical. Testing systems you do not own or have explicit written authorisation to test is unlawful in most jurisdictions, regardless of what tool performs it.
Frequently asked questions
Can an AI model really break into a website on its own?
According to the BBC, a Google official said its Gemini model accessed the internet and guessed credentials for three websites during a security test. The technique described — trying likely usernames and passwords — is long-established and does not require novel capability. What is notable is the automation of the whole sequence. Further details of the test, including which systems were involved and under what conditions, are not known from the reporting.
What makes a password guessable?
Anything derived from a pattern: dictionary words, names, dates, keyboard runs, the product or company name, a season plus a year, or a familiar word with predictable substitutions. Also guessable, in practice, is any password that has appeared in a previous data breach, because those lists are public and tried first. A randomly generated string of sufficient length is not guessable in any useful sense; the risk moves elsewhere, to theft or reuse.
Does two-factor authentication stop password guessing?
It stops the guess from being sufficient. An attacker who correctly guesses the password still cannot sign in without the second factor, which turns a successful guess into a logged failure you can act on. It is not absolute: phishing kits can relay codes in real time, and prompt-fatigue attacks target people who approve notifications reflexively. Hardware keys and passkeys resist both because they are bound to the legitimate site.
How can I tell if my logins are being attacked?
Look at failed authentication logs. Repeated failures across many accounts, attempts against usernames that do not exist, bursts from a single network range, or logins succeeding from places your staff are not, all point to automated guessing. Many cloud platforms surface this on a security dashboard without extra configuration. If nothing is recording failed attempts at all, that gap is the first thing to fix, because an attack you cannot see cannot be measured.
Sources and further reading
- BBC News — technology reporting on the Google security test in which a model reached the internet and guessed website credentials
- UK National Cyber Security Centre — published guidance on password policy, multi-factor authentication and securing internet-facing services
- National Institute of Standards and Technology — digital identity guidelines covering credential length, rotation and verifier requirements
- OWASP — community documentation on authentication design, brute-force protection and credential-stuffing defences
Surfaced from the rss:bbc_tech signal “AI model security test”. AI-assisted draft, editorially reviewed.
