Phillip Shoemaker

CEO | Al Strategy Executive | Keynote Speaker →
Focused on protecting people from online threats like Al impersonation, deepfakes, fraud, and scams.

[Phillip Shoemaker @pbsIdentity]

If you have an Apple developer account or an app in the App Store, read this now and share it.

Apple rejects your app. The notice is vague, so you fix what you reasonably think is wrong and resubmit.

Apple approves it.

Months later, with nothing in review, Apple terminates your account under 3.2(f) for “a pattern of manipulative or misleading behavior.” Every app gone. No explanation of what you did.

Your crime? Trusting the approval.

Apple’s own reviewer looked at your fix, with your rejection history in front of them, and said yes. Then Apple turned that yes into evidence against you.

So who’s misleading whom?

I ran App Review for seven years and wrote the guidelines. 3.2(f) used to mean real fraud. Now it’s being used against developers who did exactly what Apple approved.

I’ve made this Substack post free for everyone. Every developer needs to see it before this happens to them.

Share it before someone you know gets that email.

https://t.co/mWa1oGRVFH

[Phillip Shoemaker @pbsIdentity]

A school software company called Frontline Education has disclosed a breach affecting more than three million people.

According to a November 9 report from SecurityWeek, Frontline told Indiana regulators that 3,085,266 individuals were affected.

The company provides administrative software to K-12 schools. Its products help districts manage everything from employee records to student health information.

The breach occurred in August, but the full scale is only now becoming clear.

Frontline says attackers exploited a vulnerability in third-party software used by the company. Unauthorized access occurred on August 14 and 15.

The potentially exposed information includes Social Security numbers, birth dates, driver's license numbers, passport numbers, Medicaid identifiers, and student IDs.

That's a remarkable collection of sensitive information.

And it raises a question that deserves more attention.

Why are we collecting so much information about children, and how long are we keeping it?

Schools have legitimate reasons to maintain student records. They need emergency contacts, medical information, enrollment records, and other information required to educate children and keep them safe.

But every additional piece of information creates another responsibility.

A child's Social Security number doesn't become less sensitive because it's sitting in a school administration database.

Neither does their medical information.

And unlike a password, a Social Security number isn't something you can simply change after a breach.

Frontline says it has remediated the vulnerability and hasn't identified examples of the stolen information being misused.

That's reassuring, but it doesn't eliminate the potential exposure.

The company is offering two years of credit monitoring for affected adults and cyber monitoring for minors.

Here's where I think school districts need to become much more demanding customers.

When they purchase administrative software, they should ask vendors exactly what information is collected, where it's stored, who can access it, and when it's deleted.

They should also ask whether sensitive information can be encrypted or separated from everyday administrative systems.

And they should understand what happens when a vendor's own software suppliers are compromised.

The district may have excellent security practices and still be exposed through a contractor.

Parents generally don't get to choose which administrative software their child's school uses.

They don't negotiate the vendor's security requirements.

They may not even know which companies possess their children's information.

That places a greater responsibility on school districts and their technology providers.

If a school needs sensitive information to provide a service, fine. Collect what's necessary.

But retaining millions of records indefinitely because storage is cheap and deleting data is inconvenient is a terrible security strategy.

The cheapest breach to investigate is the one involving information you no longer needed to possess.

[Phillip Shoemaker @pbsIdentity]

Meta announced today that it's expanding AI-based age estimation on Instagram.

The system is designed to identify teenagers who may have entered an inaccurate birth date and place them into Teen Account protections.

That includes situations where an account claims the user is an adult but Meta's system estimates that the person is underage.

The objective is understandable.

Age-based protections are ineffective when anyone can bypass them by entering a different birth date.

Platforms need ways to identify accounts that may belong to minors.

But automated age estimation creates a second problem.

What happens when the system is wrong?

Age estimation isn't the same as establishing someone's date of birth.

An algorithm may produce a probability that someone falls within a particular age range.

That estimate can be useful.

But it isn't necessarily proof.

People develop differently.

Their appearance changes.

And the signals used to estimate age can be incomplete or misleading.

So what happens when an adult is incorrectly classified as a teenager?

Does the platform restrict their account?

Can they challenge the decision?

What information must they provide to correct it?

And does correcting the mistake require submitting sensitive identity documents?

Those questions matter.

I spent years working on App Store policy and enforcement.

One thing I learned is that a policy can be reasonable while its enforcement creates problems for legitimate users.

The practical details determine whether the system works fairly.

An automated age-estimation system needs to account for both types of error.

It may fail to identify an underage user.

Or it may incorrectly classify an adult as a minor.

The consequences are different, but both deserve measurement.

Platforms should publish meaningful information about their error rates.

They should explain what happens when a user disputes an age determination.

And they should provide correction procedures that don't collect more personal information than necessary.

There's also a privacy distinction.

A platform may need to know whether someone is above or below a particular age threshold.

That doesn't always mean it needs their full legal identity.

Age assurance systems should be designed to establish the information actually required for the decision.

For example, proving that someone is at least 18 is different from disclosing their full date of birth, legal name, and identification number.

The technology and regulatory requirements vary by jurisdiction.

But minimizing unnecessary disclosure is a sound design objective.

Meta's expansion shows that automated age estimation is becoming part of platform enforcement.

The next question is how reliably these systems make decisions and how people can correct mistakes.

Protecting minors is a legitimate objective. People also deserve an effective way to challenge an incorrect identity-related decision.

[Phillip Shoemaker @pbsIdentity]

A new proposal involving Cloudflare and Tools for Humanity is trying to address a problem that becomes more important as AI agents begin acting for people online.

How does a website distinguish a legitimate AI agent from an abusive one?

And how does it determine who is responsible for the agent's actions?

According to reporting published November 8, the proposal explores different levels of identification, reputation, and accountability for automated agents.

The idea is that websites need more information than a self-reported bot name.

That makes sense.

Today, automated traffic can identify itself using a user-agent string.

But that string is easy to fabricate.

A malicious program can claim to be a legitimate AI crawler.

An automated purchasing system can pretend to represent another service.

And a criminal can generate large numbers of requests while changing the identifiers used to describe the software.

Reliable agent authentication could help.

But identifying the software is only one part of the problem.

Imagine an AI shopping assistant acting for a customer.

The website might verify that the request came from a legitimate AI provider.

Fine.

But which customer authorized the agent?

What did the customer permit it to do?

Can the agent purchase products?

Can it access the customer's order history?

Can it change the shipping address?

And can the website hold the appropriate party accountable if something goes wrong?

Those questions aren't answered by proving that the agent belongs to a recognizable technology company.

They require a way to represent delegated authority.

I think the industry needs to distinguish at least three separate identities.

The identity of the agent operator.

The identity of the person or organization on whose behalf it acts.

And the identity associated with the specific authorization being exercised.

Those identities may be related, but they're not interchangeable.

There's also a privacy problem.

If every website requires extensive personal identification before allowing an AI agent to interact, we could create an enormous new tracking infrastructure.

A person asking an assistant to compare prices shouldn't necessarily have to disclose their legal identity to every retailer.

A website may only need evidence that an agent is authorized to perform a particular action.

For low-risk browsing, that might require very little identifying information.

For financial transactions, stronger verification may be appropriate.

The requirements should be proportional to the action.

I also want to see meaningful revocation.

If someone stops using an AI assistant, they should be able to terminate its authority.

If a business discovers that an agent has been compromised, it should be able to disable that agent without disabling every other service.

And websites should have a way to distinguish revoked credentials from active ones.

The Cloudflare proposal is an early attempt to address these questions. Its publication doesn't mean the industry has agreed on a universal standard.

But the discussion is overdue.

The goal should be proving that an agent is authorized to perform a specific action without unnecessarily exposing the person behind it.

[Phillip Shoemaker @pbsIdentity]

@MarioSaputra Yes. And as they attempt to find these apps, they are also over reaching.

[Phillip Shoemaker @pbsIdentity]

Microsoft Threat Intelligence published research on November 5 describing attackers using agentic AI tools to discover and abuse exposed credentials.

This is worth understanding because the danger isn't necessarily that AI invents a new way to break into a system.

It's that AI can help criminals perform familiar attacks with less manual work.

Consider how an exposed credential becomes a security incident.

A developer accidentally commits an API key to a public repository.

Or a configuration file is exposed through a website.

Or a service account has credentials stored somewhere they shouldn't be.

An attacker discovers the secret.

They determine which service accepts it.

They test what permissions it provides.

And they attempt to use those permissions to access additional resources.

Historically, portions of that work required manual investigation.

AI agents can help automate the sequence.

They can examine files, identify potentially useful credentials, generate requests, and interpret responses.

That changes the economics.

An attacker can investigate more potential exposures without spending the same amount of time on each one.

And that matters because organizations accumulate credentials everywhere.

Cloud services.

Development environments.

Customer databases.

Source code repositories.

AI applications.

Payment platforms.

Internal automation tools.

Many of those credentials were created for legitimate purposes.

The danger begins when they become exposed or remain active after they're no longer needed.

Here's what I think companies should be doing.

First, identify where sensitive credentials exist.

Second, remove them from places where they don't belong.

Third, restrict each credential to the minimum permissions required.

Fourth, establish expiration and rotation procedures.

And finally, monitor for unexpected use.

There's also a problem with relying on secrecy alone.

An API key may be difficult to guess.

But once it's exposed, its complexity offers little protection.

The receiving service needs to enforce limits on what that credential can do.

A key used to read a particular dataset shouldn't automatically grant administrative access to the entire cloud account.

A development credential shouldn't be able to authorize production payments.

And an AI agent shouldn't inherit unrestricted permissions simply because its developer has them.

This is where the identity problem becomes important.

We need to know which software identity is acting, what authority it possesses, and whether the requested action falls within that authority.

A valid credential proves something about authentication.

It doesn't establish that every action performed with it is appropriate.

Microsoft's research is another reminder that criminals can use the same automation capabilities businesses are adopting.

The defensive response should concentrate on limiting what compromised credentials can accomplish.

Assume a secret may eventually be exposed. Design your systems so that one exposed credential cannot become control over everything.

[Phillip Shoemaker @pbsIdentity]

A federal indictment unsealed November 5 describes one of the more disturbing examples of AI-enabled financial fraud I've seen.

Three men have been charged in an alleged international operation that prosecutors say stole approximately $129 million from businesses.

The attackers reportedly used AI-generated voices and images to impersonate company CEOs.

But the deepfakes were only part of the operation.

According to prosecutors, the criminals identified employees who had authority to approve large wire transfers.

They sent documents through electronic signature services, sometimes impersonating the company's CEO.

The documents described confidential corporate transactions and asked employees to sign nondisclosure agreements.

Then came the calls.

An employee might receive a telephone or video call from someone who sounded and looked like the CEO.

The supposed CEO would explain that the company was conducting a confidential acquisition.

The employee would then be introduced to an attorney supposedly handling the transaction.

Here's the clever part.

The attorney was also an impersonation.

The criminals reportedly used the identities of actual lawyers at major international law firms.

That meant an employee who searched for the attorney's name could find a legitimate professional.

The lawyer existed.

The law firm existed.

But the person communicating with the employee wasn't necessarily that lawyer.

This is a particularly effective form of social engineering because it creates multiple layers of apparent confirmation.

The CEO appears genuine.

The attorney has legitimate credentials.

The transaction follows a familiar corporate process.

And the employee is instructed to keep everything confidential.

Prosecutors identified six successful thefts totaling approximately $32 million, including losses involving a fintech company, hospitals, a mutual fund company, and a bank.

They attribute approximately $129 million to the broader operation.

One attempted transfer involving a New York investment bank was stopped by the bank's back office before the money left.

That detail deserves attention.

The attackers apparently succeeded in persuading an employee to authorize the payment.

But an independent financial control prevented the transfer from being completed.

That's the difference between relying on someone's judgment and building a process that can survive deception.

I think companies need to reconsider how they verify executive instructions.

Recognizing someone's voice isn't sufficient.

Seeing their face on a video call isn't sufficient.

And finding their name on a legitimate law firm's website doesn't establish that the person contacting you is actually that lawyer.

For significant financial transactions, organizations should require approval through an independently authenticated system.

Changes to payment instructions should be verified through established contact information.

And confidentiality requirements should never eliminate the controls designed to prevent unauthorized transfers.

There's another point.

We spend enormous amounts of time teaching employees to recognize phishing emails.

But what happens when the email looks professional, the documents appear legitimate, and the CEO sounds exactly right?

The problem is no longer whether the communication looks suspicious.

It's whether the organization has independent evidence that the transaction is authorized.

The defendants are presumed innocent unless proven guilty. The allegations remain subject to the judicial process.

But the attack method described in the indictment is a warning.

If your company can transfer millions of dollars because someone sounds like the CEO, your payment approval process needs work.

[Phillip Shoemaker @pbsIdentity]

The Kantara Initiative has published new work examining identity risks associated with autonomous AI agents.

The findings, reported November 4, address problems including agent impersonation, orphaned credentials, and identity drift.

Those terms sound technical.

But they describe problems that can arise inside ordinary businesses.

Start with agent impersonation.

Imagine a company uses an AI assistant to process invoices.

The assistant connects to financial systems using an authorized identity.

Now imagine an attacker creates another program that claims to be the same assistant.

If the company's systems accept that claim without reliable authentication, the attacker may gain access to functions intended for the legitimate agent.

This is similar to someone impersonating an employee.

But software can generate requests at enormous speed.

And a compromised agent identity may operate without a person noticing immediately.

The second problem is orphaned credentials.

Consider an employee who creates an AI agent to help manage customer records.

The employee leaves the company.

Their personal account is disabled.

But the agent continues operating using a separate API key or service credential.

Who owns that agent now?

Who reviews its permissions?

And who is responsible for disabling it?

An organization may have procedures for terminating employee access while lacking comparable procedures for autonomous software.

That's an identity governance problem.

The third issue is identity drift.

An agent begins with a defined purpose.

Perhaps it retrieves documents for a sales team.

Over time, developers connect it to additional applications.

They grant new permissions.

They expand its responsibilities.

Eventually, the agent can access financial information, customer records, and internal communications.

Its authority has expanded beyond its original purpose.

But the organization may still treat it as the same low-risk assistant.

That's dangerous.

Identity systems need to account for how an agent's capabilities change over time.

I think every enterprise AI agent should have a distinct identity.

That identity should be connected to an accountable human or organizational owner.

Its permissions should be documented.

Its credentials should have defined lifetimes.

And its access should be reviewed when its responsibilities change.

An agent should also be identifiable in activity logs.

If it retrieves sensitive information or modifies a business record, investigators need to know which agent performed the action.

Ideally, they should also be able to determine which task and authorization justified it.

There's another issue.

Some agents create or delegate work to other agents.

That creates relationships between systems that may operate without direct human involvement.

If one agent delegates a task, the receiving agent shouldn't automatically inherit unrestricted access to everything the first agent can reach.

Permissions need to remain limited to the work being authorized.

Kantara's work is an important contribution to the discussion because existing identity practices were largely developed around people, applications, and service accounts.

Autonomous systems introduce different patterns of delegation and decision-making.

But the underlying security principle remains familiar.

Every identity needs an accountable owner, defined permissions, and a reliable way to revoke access.

[Phillip Shoemaker @pbsIdentity]

@vadimsemenko DM me

[Phillip Shoemaker @pbsIdentity]

Apple's crackdown on AI nudify apps is justified. But innocent developers are getting terminated too.

I helped get three AI photo editors reinstated under 3.2(f).

Why did those three succeed when most won't?

I ran App Review. Here's my take on what's going wrong inside Apple.

https://t.co/z9OyuXNbfF

[Phillip Shoemaker @pbsIdentity]

New research discussed today by Help Net Security suggests consumers have clear reservations about autonomous AI agents.

According to Okta's 2026 Customer Identity Trends Report, only 37% of North American consumers surveyed were ready to let AI make final decisions and act on their behalf, or handle routine, less important decisions.

But willingness exceeded 50% for most use cases when people could approve or undo an action.

That difference is interesting.

It suggests that consumer acceptance depends partly on how much control people retain.

Consider an AI assistant that books travel.

You ask it to find a flight to Bangkok.

It searches several airlines, compares prices, and identifies a reasonable itinerary.

So far, the assistant is performing research.

Now imagine it purchases a nonrefundable ticket.

Or changes an existing reservation.

Or books a hotel using your stored credit card.

Those actions have consequences.

The assistant may have correctly understood the destination.

But did it understand your preferred airline?

Your budget?

Your baggage requirements?

Whether you wanted a refundable ticket?

And whether you actually authorized the purchase?

A user might be comfortable allowing an AI system to research travel options while requiring approval before money changes hands.

That seems entirely reasonable.

The same issue appears in other industries.

An AI shopping assistant can compare products.

But the customer may want to approve the final price.

A financial assistant can prepare a payment.

But the account holder may want to confirm the recipient.

A scheduling assistant can identify available appointments.

But the user may want to approve cancellations that incur fees.

The distinction is between giving an agent access to information and authorizing a specific action.

Many current digital permission systems were designed around applications.

A user authorizes an application to access a calendar.

Or grants a service access to payment information.

But an autonomous agent can make decisions within those systems.

That introduces a different requirement.

The user needs to understand which decisions the agent is permitted to make independently.

I think AI products should make those boundaries explicit.

An assistant might be authorized to spend up to $50 on a particular category of purchase.

It might be permitted to modify calendar events that don't involve other participants.

Or it might require confirmation before sharing personal information with a new service.

Those permissions should be enforceable by the underlying systems.

A statement in an AI prompt isn't sufficient protection for a high-risk financial action.

There's also a practical question about reversibility.

The survey suggests people become more comfortable when they can approve or undo an action.

But some actions cannot be fully reversed.

An email containing confidential information may already have reached its recipient.

A nonrefundable purchase may incur a penalty.

And information disclosed to an outside service may already have been copied.

For those actions, approval before execution is particularly important.

The Okta results are survey findings, rather than proof of how every consumer will behave in real transactions.

But they offer a useful product-design lesson.

People appear more willing to delegate work to AI when they retain meaningful control over consequential decisions.

[Phillip Shoemaker @pbsIdentity]

@noreasonspec Thank you!

[Phillip Shoemaker @pbsIdentity]

The cyberattacks affecting supermarket refrigeration systems across Europe have taken a more troubling turn.

On November 4, Reuters reported that refrigeration equipment at three regional blood banks in France had also been affected.

The incidents occurred overnight between November 1 and 2.

Staff moved blood products into backup storage to protect the supplies.

According to France's health ministry, the blood supplies were protected.

That last detail matters.

The incident demonstrates the consequences of a cyberattack against equipment that performs a physical function.

Consider what refrigeration means inside a blood bank.

Blood products must be maintained under appropriate storage conditions.

Temperature control is part of maintaining their safety and usability.

A refrigerator isn't simply an appliance in that environment.

It's part of the infrastructure supporting medical care.

If an attacker can manipulate its controls, the consequences may extend beyond damaged equipment.

The attack could threaten valuable medical supplies and disrupt operations.

The reported incidents also affected supermarkets across several European countries.

Some stores lost substantial amounts of food when refrigeration temperatures rose.

The precise technical method and responsibility for the attacks remain under investigation.

We shouldn't assume that every affected organization was compromised through the same vulnerability.

But the incidents expose a security issue that businesses often underestimate.

Modern equipment frequently depends on network-connected controllers.

Those controllers may communicate with remote management systems.

A vendor may be able to change settings without visiting the facility.

That provides useful capabilities.

Technicians can diagnose problems remotely.

Businesses can monitor temperatures across many locations.

And operators can receive alerts when equipment begins malfunctioning.

But remote control also creates a pathway that needs protection.

Who can change the temperature?

Which accounts have administrative access?

Can a compromised vendor account affect multiple facilities?

Can equipment continue operating safely if its network connection is interrupted?

And can staff override dangerous settings locally?

These questions belong in a cybersecurity assessment.

They also belong in operational planning.

The French blood banks reportedly protected their supplies by moving them into backup storage.

That illustrates the value of having a recovery procedure that doesn't depend entirely on the affected system.

A security program needs to account for what happens when prevention fails.

In some environments, the appropriate response is to isolate a compromised system.

In others, operators may need to switch to backup equipment or manually controlled processes.

Those procedures should be tested before an emergency.

There's another important distinction.

Traditional cybersecurity programs often prioritize the confidentiality of information.

That's appropriate for systems containing customer records, medical information, and financial data.

But connected physical equipment introduces safety and availability concerns.

An attacker may cause serious damage without stealing a single record.

Organizations need to assess connected systems according to the physical operations they control.

A refrigerator connected to the internet deserves a security assessment based on what happens when someone changes its settings without authorization.

[Phillip Shoemaker @pbsIdentity]

On November 4, Singapore Airlines disclosed that approximately 46,000 booking records may have been affected by a cybersecurity incident involving its reservation technology provider, Amadeus.

The incident raises a question that every company collecting customer information should be able to answer.

Where does that information go after the customer provides it?

Think about booking an international flight.

You give the airline your name, contact information, travel dates, and other details required for the reservation.

You probably think of the airline as the organization responsible for that information.

But airlines depend on reservation platforms and other technology providers to operate their businesses.

Customer information can pass through systems the passenger has never heard of.

Those systems may be essential to completing a booking.

They also create additional places where sensitive information must be protected.

The reported Singapore Airlines incident illustrates that dependency.

A customer can choose a reputable airline, use a strong password, and enable available account protections.

Those actions won't necessarily prevent an incident involving the airline's technology provider.

This is why companies need to examine security beyond their own applications.

Which vendors process customer information?

What information can those vendors access?

How long do they retain it?

Which subcontractors can receive it?

And how quickly must they notify the airline when something goes wrong?

There's also a question about the information collected during a reservation.

An airline may need a passenger's contact details to communicate schedule changes.

It may need passport information for certain international journeys.

But that doesn't establish that every system involved in the booking needs permanent access to every field.

Companies should limit access according to the actual function being performed.

A service responsible for sending flight notifications shouldn't automatically need unrestricted access to identity documents.

An analytics service shouldn't receive sensitive passenger information simply because the reservation platform contains it.

And a vendor shouldn't retain personal information indefinitely without a legitimate business or legal reason.

The same principle applies to healthcare, financial services, and online commerce.

Customers interact with a recognizable brand.

Behind that brand sits a network of service providers.

Each connection creates responsibilities for access control, monitoring, and data retention.

The investigation into the Amadeus incident is still developing. The reported number concerns potentially affected booking records and shouldn't be treated as a confirmed count of distinct individuals whose information was stolen.

But the broader security question is already clear.

When a company collects information from customers, it needs to understand where that information is processed and which other organizations can access it.

Customers shouldn't have to investigate a company's entire technology supply chain to understand who is handling their personal information.

[Phillip Shoemaker @pbsIdentity]

@TFTC21 @MartyBent This is the nature of the honeypot.

[Phillip Shoemaker @pbsIdentity]

Security startup Sentra has raised $150 million in a Series C financing round.

The investment was led by Capital One Ventures.

According to The Wall Street Journal, the company has now raised more than $260 million.

Sentra develops technology that maps an organization's information, identifies sensitive data, and helps security teams understand which systems and AI agents can access it.

That might sound like ordinary data security.

But AI agents make the problem considerably more complicated.

Consider a company with thousands of employees.

It maintains customer records, financial documents, product specifications, employee information, and internal communications.

Different employees have access to different information.

Those permissions are usually associated with their jobs.

Now imagine employees begin building their own AI agents.

A salesperson creates an assistant that reads customer records.

A product manager builds an agent that examines internal documents.

A developer connects an AI coding tool to source code and cloud infrastructure.

Each agent may inherit access from the employee who created it.

And the organization may not have a complete inventory of those agents.

That's a serious governance problem.

An employee may have legitimate permission to read confidential information.

But an agent operating with that employee's credentials may retrieve far more information than the original task requires.

It may combine data from several systems.

It may send information to outside services.

And it may perform actions that the employee never intended.

This creates a distinction between the identity of the employee and the authority of the agent.

The employee might be permitted to access a customer database.

That doesn't automatically mean every agent created by that employee should have the same access.

An agent should have its own identifiable permissions.

Those permissions should be limited to the work it's authorized to perform.

And the organization should be able to revoke them independently.

Sentra says its technology helps companies identify sensitive information and understand how AI agents interact with it.

The company also focuses on removing unnecessary or redundant sensitive data.

That's an important part of the problem.

Organizations often retain information long after its original purpose has ended.

They create copies for testing.

They export data for analysis.

They maintain old databases.

And they grant permissions that remain active after employees change roles.

AI agents can make those existing weaknesses more consequential.

A system capable of searching across many applications may discover information that individual employees rarely accessed.

That doesn't mean the agent is malicious.

It means the organization needs to understand what information is available and whether the agent has a legitimate reason to retrieve it.

The investment in Sentra reflects commercial demand for tools addressing those concerns.

It doesn't establish that any particular product can prevent every unauthorized agent action.

Companies still need to evaluate how the controls work.

Can they identify agents created outside approved processes?

Can they determine which credentials those agents use?

Can they restrict access to specific datasets?

And can they produce reliable records when an agent accesses sensitive information?

I think the first question every organization should ask is straightforward.

Do we actually know which AI agents can access our sensitive information?

If the answer is no, the company has work to do before expanding autonomous access.

[Phillip Shoemaker @pbsIdentity]

Today, Tencent announced a new AI model called Hy4.

The company says it deliberately limited the cybersecurity information used during training.

The model was trained on defensive tasks, including identifying and repairing software vulnerabilities.

Tencent says it excluded material specifically focused on creating hacking tools, breaking into systems, and probing targets for weaknesses.

The objective is to produce a model that can help defenders without substantially increasing offensive capabilities.

According to Reuters, Tencent says its internal testing found no increased ability to conduct cyberattacks or bypass security protections.

The company plans to release the model's weights and publish additional information about its safety evaluations.

I think this is worth examining because cybersecurity creates an unusual problem for AI developers.

Many defensive and offensive skills overlap.

A security researcher needs to understand how vulnerabilities work.

They may need to reproduce an exploit to confirm that a weakness exists.

They may need to analyze malicious code.

And they may need to test whether a software patch actually prevents exploitation.

An attacker can use some of those same capabilities.

So how do you build a powerful defensive model without making it equally useful for offensive operations?

Tencent's approach is to limit certain categories of training material.

That's one possible strategy.

But the effectiveness needs independent testing.

Consider a model that understands software vulnerabilities.

Even if it wasn't explicitly trained to create hacking tools, it may still be able to combine programming knowledge with its understanding of vulnerable code.

That doesn't establish that it will successfully produce dangerous capabilities.

It means the training restrictions need to be evaluated against realistic tasks.

The company reports that its internal tests didn't identify an increase in offensive capability.

That's useful preliminary information.

But independent researchers need to examine the model under different conditions.

Can it identify vulnerabilities accurately?

Can it recommend effective patches?

Does it produce false positives?

Can users manipulate it into providing offensive assistance?

And do its safeguards remain effective when the model is modified?

The planned release of model weights makes the last question particularly important.

When a model can be downloaded and operated independently, its original developer has limited control over how people configure or modify it.

That's one reason the debate over open-weight cybersecurity models is complicated.

Independent access can help defenders examine software without sending sensitive information to outside providers.

It can also make powerful capabilities available to people the original developer cannot monitor.

I don't think the answer is to assume that every cybersecurity model should be restricted or that every open release is harmless.

We need reliable evidence about what these systems can actually do.

Tencent's announcement provides an opportunity to test whether restricting particular training data meaningfully reduces dangerous capabilities while preserving defensive usefulness.

The results should be reproducible.

A model's security claims are only as credible as the testing used to establish them.

[Phillip Shoemaker @pbsIdentity]

Apple's latest annual 10-K contains an interesting acknowledgment.

AI agents may perform actions that weren't directed, instructed, or authorized.

The company identifies risks involving agents that access systems, modify code, send communications, and complete transactions.

Apple also warns about agents producing misleading information or behaving in ways that exceed their intended permissions.

This is particularly interesting coming from Apple.

For decades, the company has built products around controlled access to hardware, software, and user information.

Its platforms rely on permissions.

Applications request access to cameras, microphones, contacts, and other resources.

Users can approve or deny those requests.

And the operating system attempts to enforce those decisions.

I spent years working on App Store review and enforcement.

One of the fundamental questions in that work was whether an application performed the functions it represented to users.

Now consider what happens when an application contains an AI agent.

The user authorizes the application to perform a task.

But the agent may independently determine how to accomplish it.

Imagine asking an assistant to arrange a business trip.

The assistant searches flights.

It examines your calendar.

It retrieves information from your email.

And it begins making reservations.

Which actions did you actually authorize?

Did you approve a particular flight?

A specific price?

A hotel cancellation policy?

Or permission to share your personal information with third-party services?

The assistant may have access to everything necessary to complete the task.

That doesn't establish that every decision it makes is authorized.

This creates a problem for traditional application permissions.

A user might grant an application access to their email.

But that permission doesn't necessarily mean the user wants the application forwarding messages to outside parties.

An application might have permission to access payment information.

That doesn't mean it should independently authorize purchases without appropriate limits.

And an AI coding tool might have permission to examine source code.

That doesn't establish permission to deploy changes into production.

The underlying issue is that access permissions and authorization for individual actions are different things.

Apple's warning acknowledges that autonomous systems can behave outside their intended boundaries.

That raises questions for the entire application ecosystem.

How should an application disclose the actions its agents can perform?

Which actions require explicit confirmation?

How can users review what an agent has done?

Can they reverse an action?

And what happens when an agent exceeds its instructions?

There's also an enforcement question.

If an application uses an AI agent to perform a prohibited action, who is responsible?

The developer?

The provider of the underlying AI model?

The service that executes the action?

Or some combination of those parties?

The answer may depend on the circumstances and applicable law.

But responsibility needs to be established before these systems become widely deployed.

I think Apple's disclosure is significant because it describes unauthorized agent behavior as a material business risk.

The company is acknowledging that autonomous software introduces risks that traditional software controls may not adequately address.

The next step is turning that acknowledgment into specific product requirements.

Users should be able to understand what an agent can do, restrict its authority, and review its actions.

An AI agent shouldn't receive unlimited authority simply because the application containing it has been approved.

[Phillip Shoemaker @pbsIdentity]

We finally have more details about how attackers stole approximately $6.34 billion from Binance.

And the story is considerably more interesting than someone stealing a password.

According to reporting published November 3, the attack involved a months-long operation targeting employees responsible for cryptocurrency wallet infrastructure.

The first compromise reportedly happened in June.

A Binance engineer downloaded a malicious software package while searching for an AI coding tool.

The company replaced the affected computer and rotated credentials.

But the attackers had already learned something valuable.

They knew which employees worked on the systems responsible for managing cryptocurrency wallets.

Then, in September, the attackers approached another engineer through a legitimate job-search platform.

They posed as a prospective employer.

They conducted fake interviews.

And they persuaded the engineer to install malware as part of the recruitment process.

Think about that.

The attackers didn't need to send an obviously suspicious email promising a lottery prize.

They created an interaction that resembled a legitimate professional opportunity.

The engineer was participating in what appeared to be a normal hiring process.

That gave the attackers a reason to request technical work.

And a reason to ask the engineer to install software.

The attack reportedly continued through October.

On October 20, the attackers used compromised access and Binance's internal AI tooling to reach additional systems.

On October 29, they used a compromised developer's computer and previously stolen credentials to execute the transactions that drained the exchange's hot wallets.

The FBI has attributed the theft to North Korean hackers.

North Korea disputes the accusation.

Binance says approximately $2.85 billion of the stolen assets has been frozen or intercepted.

The company's investigation continues.

Here's what I find most interesting.

The attackers exploited several different forms of trust.

The engineer trusted what appeared to be a legitimate software installation.

Another employee trusted what appeared to be a genuine recruiter.

The company's internal systems trusted authenticated employees and services.

And the wallet infrastructure ultimately processed unauthorized transactions.

Each step helped the attackers reach the next one.

This is why cybersecurity can't depend exclusively on establishing that someone has valid credentials.

A legitimate employee can be manipulated.

A trusted computer can be compromised.

And an authorized application can be used for an unauthorized purpose.

The involvement of an internal AI tool adds another issue.

Organizations need to understand which information their AI systems can retrieve and which actions they can perform.

If an attacker compromises an employee account, what can the attacker do through the AI tools associated with that account?

Can the agent retrieve sensitive configuration information?

Can it interact with privileged systems?

Can it execute code?

And does the organization maintain records showing what happened?

These questions should be answered before an incident.

There's also a lesson for anyone interviewing for a technical job.

A recruiter asking you to install software or execute code during an interview should trigger additional verification.

Contact the employer through an independently established channel.

Confirm the recruiter's identity.

And avoid running unfamiliar software on a computer that contains sensitive company information.

The Binance incident is a particularly expensive demonstration of a familiar security problem.

Criminals don't always need to defeat sophisticated cryptography.

Sometimes they persuade someone with legitimate access to perform the first dangerous action.

[Phillip Shoemaker @pbsIdentity]

Singapore-based financial comparison platform MoneySmart has disclosed a cybersecurity incident affecting customers in Singapore and Hong Kong.

The company detected unauthorized activity on October 29.

Its investigation found that an unauthorized party had accessed internal systems and copied personal information belonging to some customers.

The potentially affected information includes names, dates of birth, nationalities, identification numbers, contact details, income brackets, and information about financial products.

MoneySmart began contacting affected customers today.

The company hasn't publicly disclosed the total number of people affected.

It says it has restricted the unauthorized access, strengthened security controls, and engaged external investigators.

Regulators in Singapore and Hong Kong have been notified.

Here's what concerns me about this type of breach.

A financial comparison service can collect a remarkably detailed picture of someone's life.

The customer may visit to compare credit cards.

Or apply for a personal loan.

Or examine insurance products.

To provide those services, the platform may collect information about income, employment, financial circumstances, and personal identity.

Individually, those details serve legitimate purposes.

But when combined, they can become valuable to criminals.

Imagine an attacker knows someone's name, phone number, income bracket, and the financial products they've considered.

The attacker could use that information to construct a convincing message.

They might claim to represent a bank.

They might refer to a genuine financial product.

And they might use personal details to make the communication appear legitimate.

That doesn't mean every affected customer will be targeted.

It means the exposed information could make certain impersonation attempts more convincing.

There's another distinction worth understanding.

A financial comparison platform isn't necessarily the bank that ultimately provides the financial product.

The customer may trust the bank's security practices.

But their information may also exist in the systems of comparison services, brokers, marketing partners, and other intermediaries.

Each organization that retains the information creates another potential point of exposure.

That's why companies should examine whether they need to retain every piece of information collected during a transaction.

Does a comparison service need to keep an identification number after the application is completed?

Does it need to retain detailed financial information indefinitely?

Can records be deleted or minimized once their original purpose has been fulfilled?

The answers depend on legal obligations and business requirements.

But data retention should be a deliberate decision.

Customers also need clear information about what happened.

Which records were accessed?

What information was copied?

When did the unauthorized access occur?

And what steps should affected customers take?

MoneySmart's investigation is continuing.

The available reporting doesn't establish that attackers have used the information to commit additional fraud.

But the potential exposure of identity and financial information is serious.

Organizations should collect the information they need, protect it appropriately, and retain it only as long as there's a legitimate reason to keep it.

[Phillip Shoemaker @pbsIdentity]

Today is Election Day in the United States.

And a federal court has issued a ruling involving the use of government identity information.

US District Judge Tanya Chutkan temporarily barred the Justice Department and Department of Homeland Security from sending states lists of voters suspected of being noncitizens or urging officials to segregate or withhold their ballots based on those lists.

The ruling concerns the reliability of the information and the government's authority to use it.

The administration argues that the effort is intended to enforce the federal prohibition on noncitizen voting.

Voting rights and privacy organizations argue that the process risks incorrectly identifying eligible voters and violates privacy protections.

The judge expressed concern that unreliable data could disenfranchise legitimate voters.

The order is temporary.

It doesn't establish that every government record is incorrect.

And it doesn't eliminate the legal requirement that voters meet applicable eligibility rules.

But it raises a question that extends far beyond elections.

What happens when an organization treats a database match as proof of someone's identity or legal status?

Consider two records.

One contains a person's name and date of birth.

Another contains similar information.

A matching system determines that the records probably refer to the same person.

That can be useful.

But the match itself may be incorrect.

People share names.

Records contain outdated information.

Dates can be entered incorrectly.

And an individual's status may change after a record was created.

A system that produces a probable match doesn't necessarily establish a current legal fact.

That distinction becomes particularly important when the result affects someone's rights.

In financial services, an incorrect identity match can prevent someone from opening an account.

In employment, it can cause a background check to associate someone with another person's records.

In healthcare, it can contribute to mistakes involving patient information.

And in elections, it can affect whether an eligible voter is permitted to cast a ballot that counts.

The consequences depend on the application.

But the underlying data problem is similar.

An organization needs to understand what its records establish and how reliable they are.

It also needs a process for correcting errors.

That process matters because people may have little control over the information stored about them.

They may not know which databases were consulted.

They may not know why a match occurred.

And they may not have an easy way to challenge the result.

The government's interest in enforcing election eligibility requirements is legitimate.

So is the public's interest in ensuring that eligible voters aren't incorrectly excluded.

Those objectives require accurate information and appropriate procedures.

I think identity systems should be evaluated according to the consequences of incorrect decisions.

A false match in a low-risk application might be inconvenient.

A false match that affects someone's legal rights demands stronger safeguards.

That includes reliable source data, documented decision rules, and meaningful opportunities to correct mistakes.

A database match is evidence to evaluate. Its reliability needs to be established before it becomes the basis for a consequential decision.