Phillip Shoemaker

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.

phillipshoemaker.substack.com/p/apple-approv…

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.

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.

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.

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.