Whether Muse succeeds depends on whether people decide to trust Meta with that scope. That's a fair question but not the one I care about here. The useful question applies to every agent in this category, including the ones you'll be offered next month:

**What exactly are you granting, and what keeps working after you stop watching?**

## An agent is not an app

This is the distinction most people miss, and it's the whole risk model.

An **app** asks for permission and runs when you open it. Access is bounded by your attention. If it does something unexpected, you're usually looking at the screen.

An **agent** differs in two ways:

1. **Standing access.** The grant persists across sessions rather than being requested each time.

2. **It acts on your behalf.** The output isn't just data leaving your device — it's things happening in the world. An email sent. A booking made. A payment authorised.

Combine those and a compromise changes category. A leaked copy of your calendar is bad. An agent that can read your calendar, write your email and move money is closer to someone holding your phone, unlocked, for as long as the token lives.

## Six checks before you grant anything

### 1. Separate read from write

"Access your email" can mean reading it to summarise your day, or sending mail *as you*. These are not the same permission and they are not the same risk. If the grant screen doesn't distinguish them, assume the broader one.

From an OAuth standpoint this is just scope granularity: `mail.read` versus `mail.send`. Read is already significant. Send-as-you is the one that turns a mistake into an incident.

### 2. Look at scope, not just category

Full-mailbox access and access to one label are both "email access." Same for calendars: every calendar versus one you create specifically for the agent. If the tool supports scoping, use it. If it doesn't, that tells you how the vendor thinks about your data.

### 3. Two questions, not one

People collapse these, but they're separate:

- Is processing local or in the vendor's cloud?

- Does your content become training data?

The second matters more than expected, because "we don't train on your data" and "we don't train on your data by default, but you can opt in" are very different sentences that look nearly identical on a settings page.

### 4. Find the revocation path *before* you need it

Two separate things:

- Where do I turn this off?

- Does turning it off **delete what it already collected**?

These are frequently different processes, and the second is usually buried. An agent you can't cleanly revoke is a commitment, not a feature. Check the connected-apps panel of the granting account and see whether revocation also invalidates the issued tokens — sometimes it doesn't.

### 5. Decide what it may do with third parties

An agent that can negotiate or transact is acting toward other people *in your name*. That's a much larger grant than one that only organises information you already have. If payment authority is involved, look for per-action confirmation and a spend ceiling rather than blanket authorisation.

### 6. Demand an audit trail

You should be able to see what the agent did, when, and on whose instruction. Without a log you can't detect a wrong action and can't reconstruct one after the fact. No activity history means every action is unverifiable.

## The part that worries me most

An agent holding your email and calendar isn't only a privacy question. It's the best phishing pretext ever assembled.

Everything a convincing lure needs — who you talk to, what you're working on, when you're away, what you bought — is exactly what these agents are being given. If that store is reachable, the messages produced will be better than anything in circulation today.

Attackers are already moving from stealing passwords to borrowing legitimate access. A related operation I wrote about, BigBear, took **474 Microsoft 365 sessions with MFA fully satisfied** using a relay proxy. An agent account is the most concentrated form of legitimate access most people will ever hold.

## If you run a system others use

An employee granting an agent access to a work mailbox is effectively granting a third party access to company data. Not always wrong — frequently useful — but it should be a decision with an owner, not something that happens during a product tour.

The minimum:

- Know which agents hold tokens against your tenant.

- Log what they do.

- Make sure offboarding revokes them. Offboarding that closes the account but leaves the agent's OAuth token alive is easy to create and very hard to notice.

## The honest read

I'm not going to tell you not to use these tools. Some will save real time, and refusing them on principle isn't a strategy.

But the permission screen is the wrong place to start thinking. By the time it appears, the decision is framed as "allow access to continue," and the interesting questions — what persists, what it can do without you, what happens on revocation — have already been settled somewhere else, usually in a settings page nobody opens.

Read those first. The agent can wait thirty seconds.

---

Originally published at [CyberPicks](https://cyberpicks.org/guides/ai-agent-permission-checklist).

---

*Originally published at https://cyberpicks.org/guides/ai-agent-permission-checklist\*

Confirmed total: **219,665 affected users** (~160,000 South Korea, 48,000 Japan, 4,218 Taiwan, 1,591 Thailand, 481 mainland China, 5,308 elsewhere).

I'm not writing about the breach count. I'm writing about the entry point, because it's the one that keeps showing up and the one that's hardest to catch in review.

## No exploit was involved

This wasn't a memory corruption bug, a stolen admin credential, or an unpatched CVE. Nothing was technically *broken*. An endpoint that was supposed to answer "what are this user's consultation records" answered for more records than it should have, to more callers than it should have.

That's broken object-level authorization — the API security category where the endpoint authenticates the caller but fails to verify that the caller is entitled to *the specific object* being requested. It survives code review because the function looks correct in isolation:

```python

@app.get("/api/consultations/{record_id}")

def get_consultation(record_id: str, user: User = Depends(current_user)):

return db.consultations.find(record_id) # authenticated, not authorized

```

The reviewer sees `current_user`, sees that unauthenticated requests are rejected, and moves on. The missing check is the relationship between `user` and `record_id`, and it isn't visible in this function at all.

## Why it's hard to catch

- **It produces valid responses.** Nothing throws. Status codes are 200. Error-rate alerting sees nothing unusual.

- **It looks like normal traffic.** Sequential or enumerable IDs are indistinguishable from legitimate use without behavioural baselining.

- **Unit tests pass.** You test that a user can fetch *their* record. Almost nobody writes the negative test for fetching *someone else's*.

- **It's not in the dependency tree.** No scanner will flag it. This is first-party logic.

## The detail that should worry you most

The attacker came back through a **second path the day after the first was closed**.

That's the part I keep thinking about. Closing one route didn't end the incident, because the underlying authorization model was the problem — not the one endpoint that got caught. Whoever this was knew the system well enough to have a fallback ready, which means they'd mapped it.

If your incident response is "block the route that was abused," you're treating the symptom. The fix is fixing the authorization layer; otherwise you're playing whack-a-mole against someone who has already read your codebase's shape.

## What to actually check in your own API

1. **Every object-scoped endpoint, list them.** For each one, write down where the ownership check happens. If the answer is "in the service layer" or "the ORM scopes it," verify it — don't assume.

2. **Write the negative test.** For each of those endpoints, add a test where user A requests user B's resource. It should fail. If that test doesn't exist, the guarantee doesn't either.

3. **Prefer non-enumerable identifiers.** Sequential integers turn a single authorization bug into a full-table dump. UUIDs don't fix BOLA, but they raise the cost of exploitation dramatically.

4. **Rate-limit per identity, not per IP.** Abnormal access to a lookup API is detectable — but only if you're counting per-authenticated-principal rather than per-source-address.

5. **Log object access with both IDs.** Your audit log needs the requesting identity *and* the object accessed, or you cannot reconstruct scope after the fact.

## The data made it worse

The exposed fields split into two layers. First, ordinary identity data: name, phone, email, date of birth, gender, residence, social account IDs, IP and device details.

Second, and this is why it's not a routine breach: procedures enquired about, clinic and doctor names, **the stated reason for seeking treatment**, clinical progress notes, **uploaded consultation photographs**, appointment times, and treatment and payment details.

A password is changed in a minute. A card is cancelled with a phone call. A pre-procedure photograph of someone's face, tied to their name and the thing they were self-conscious about, has no revocation mechanism. Korean security professionals quoted in local coverage warned about extortion using exactly that material.

That's the design lesson too: the reason this leak is catastrophic rather than merely bad is *what was stored in a reachable place*. Minimize the blast radius before you worry about the perimeter.

---

Originally published at [CyberPicks](https://cyberpicks.org/guides/gangnam-unni-medical-photo-breach).

---

*Originally published at https://cyberpicks.org/guides/gangnam-unni-medical-photo-breach\*

CloudSEK got access to the admin panel of a phishing operation called BigBear 2.0 and read its own records instead of inferring from the outside. What was in there is one of the clearer published pictures of how industrial credential theft actually runs:

- **5,137 records** spanning **461 organisations**

- **1,032 plaintext passwords**

- **4,148 session cookies**

- **474 confirmed sessions where MFA had been bypassed entirely**

Those 474 are the number worth staring at. Not attempts. Finished jobs where the second factor was satisfied and the account opened anyway.

## The mechanism: a proxy, not a fake page

The old phishing model was a counterfeit login form. It harvested your password and then failed, because the TOTP code you generated seconds later was useless to an attacker who needed it *right then*.

Adversary-in-the-middle (AiTM) kits solved that by removing the counterfeit part. BigBear runs **Evilginx2**, which is a reverse proxy:

1. You get a link and land on what genuinely *is* Microsoft's login page, served through the attacker's domain.

2. You type your password.

3. Microsoft asks for your second factor. You supply it.

4. Everything is relayed to Microsoft in real time.

5. Microsoft is satisfied and issues a session cookie — which returns **through the proxy**, where the attacker keeps a copy.

Nothing was guessed. Nothing was cracked. The attacker watched a legitimate authentication happen and kept the receipt.

That cookie is the entire prize. Replaying it gives access to Outlook, calendar, Teams conversations, and everything in SharePoint and OneDrive, without triggering another prompt.

## They deliberately disabled the one control that would have stopped them

FIDO2 hardware keys and passkeys defeat relay attacks completely. The credential is cryptographically bound to the origin. A proxied login presents the wrong origin, the key refuses to sign, and the attack fails with no user judgement required.

BigBear knew this. Its pages shipped custom JavaScript to **disable FIDO2 and WebAuthn**. With the strong option gone, users fell back to whatever remained — SMS codes and push approvals. Both are relay-friendly: you read six digits off your screen into the proxy, or you tap approve on a prompt you were already expecting.

If your org rolled out MFA and stopped there, that's the gap. "A second factor exists" and "a phishing-resistant second factor exists" are different statements.

## Residential proxies hide it from exactly the people looking

The operation routed through a residential proxy pool covering **69 countries**. Two jobs at once:

- Login attempts appear to come from real home connections in plausible locations, which helps them survive risk scoring.

- The pool actively filtered out visitors from data centres and VPNs — which is how researchers and scanners normally find these kits.

So a security team that tried to visit the phishing page from a corporate network or a cloud VM often saw nothing at all.

## It's a business with customers

The panel was run by an operator using the handle "General Boss" and rented through a multi-user interface to **at least five affiliates**. Harvested credentials were pushed out in real time via a Telegram bot.

That structure explains the volume better than any technical detail. This is phishing-as-a-service: the person who builds the kit isn't the person who writes the emails, and the person who steals the session isn't the person who uses it. Some infrastructure has been taken down, but CloudSEK reported the operation was still active while it was being investigated.

## What actually helps, ordered by risk removed

1. **Move to phishing-resistant factors.** Hardware keys and passkeys are the only second factors that fail closed when the domain is wrong. Roll out to admins and finance first — they're the highest-value targets.

2. **Shorten session lifetime and bind sessions to device state.** A stolen cookie is useful for as long as the IdP accepts it. Conditional Access policies that re-evaluate compliance and location cut that window down.

3. **Treat unexpected MFA prompts as hostile.** Push fatigue *is* the attack. "Approve because it's probably me" is the whole mechanism.

4. **Remove SMS as an option where you can.** It's the fallback these kits are engineered to force you into.

5. **Assume mailbox access means broad access.** Once a session is held, password reset flows for other services are the next step.

## The uncomfortable part

MFA was never a wall. It was a speed bump that raised the cost of credential reuse, and kits like this one route around it by not reusing anything. The 474 sessions aren't a failure of the users who typed their codes — they typed them into a real Microsoft page that asked for them.

"Turn on MFA" was the right instruction in 2018. In 2026 the instruction is "turn on MFA that cannot be relayed," and anything less is a checkbox that looks like protection while delivering considerably less than people assume.

---

Originally published at [CyberPicks](https://cyberpicks.org/guides/bigbear-mfa-bypass-evilginx).

---

*Originally published at https://cyberpicks.org/guides/bigbear-mfa-bypass-evilginx\*