WTF Happens When Your Team Uses Muse or Grok

By Mark Rogge, CEO of EnforceAuth. This stitches together the eight-post "WTF happens when your team uses…" series that ran on LinkedIn and X this week. The reference architecture it points to lives in the Cyber60 white paper on the EnforceAuth blog.

Part one: Muse

1. Your employees installed it before security heard the name

Meta launched Muse on September 8. Five days later it was the #1 free app in the U.S., past ChatGPT, with 730,000 downloads in that window. Analysts are projecting 100 million users inside a year.

Muse isn't a chatbot. It's a do-it-for-me agent. Give it a goal and it books, buys, emails, fills forms and works your calendar, running in a cloud VM that keeps going after you close the app. On September 29 Meta added "Muse for Small Business," wired into Asana, Zoom and friends, one day after announcing the Meta Enterprise Platform.

Here's the WTF: nobody filed a ticket. Nobody added it to the vendor register. It's on personal phones, connected to work email and work calendars, because that's where the tasks are. This isn't a Meta problem. It's a pattern.

2. How it gets in

Muse has two ways into the tools your business runs on. If the app has a public API, the employee hands Muse their credentials; Meta says those go into secure storage and Muse never sees the password. Muse then acts with the employee's full permissions. If there's no API, Muse drives a browser inside a Meta-run virtual machine, logs in as the employee, and clicks through your app like a person. Your app sees a human session. It isn't one.

Amazon blocked Muse on September 20 for exactly this. Amazon's complaint: Muse doesn't identify itself as an agent, and appears to capture and store customer credentials. Meta disputes the second part. The two accounts conflict, and that's the point: neither you nor your SaaS vendor can currently tell the difference between your employee and an agent running as your employee.

To be fair to Meta: Muse asks for approval before sensitive actions like sending email or buying, and a separate monitoring agent, Sentinel, must approve anything Muse sends to the internet. Those are real safeguards. They live on Meta's side. Nothing on your side decides whether the action Muse is about to take inside your CRM, your billing system, your ticketing queue, is one that agent should be allowed to take.

3. The log

Count the entries in your audit log that say "Muse did this." Zero. Every action Muse takes is attributed to the employee whose credentials it holds. Their email sent the message. Their session changed the record. Their user ID approved the request.

Play forward six months. An auditor asks who moved the money, who exported the list, who changed the vendor's bank details. The honest answer is: "the employee, or an agent running in Menlo Park as them. We can't tell."

The Lightspeed Cyber60 survey found 26% of enterprises already pass human credentials to AI agents, and that suspected-but-unconfirmed AI incidents rose to 63%. Those two numbers are the same number. If you can't attribute, you can't confirm. DORA, SOX, HIPAA and the EU AI Act all assume you can say who acted. "A human or their delegate, indistinguishably" is not an answer any of them accept.

4. What you actually do about it

The reflex is to block it. That worked for Amazon, with lawyers. It won't work for you, because next month it's a different agent, and the month after that it's the one your CEO uses. The durable fix is to stop caring which agent it is and start deciding what any agent may do. Three moves, in order:

Give agents their own identity. Not the employee's. Where a vendor's agent can't be distinguished today, treat the employee's session as potentially delegated and scope it accordingly.

Put a decision point at the resource, not around the model. Meta's Sentinel approves what Muse sends out. Nothing approves what Muse does inside your systems. A policy enforcement point at your API gateway or MCP layer evaluates every action: allow, deny, or escalate to a named human.

Keep the log. Every decision, tied to the policy version that made it, replayable. That's the difference between "we suspect" and "we know."

Polite AI isn't secure AI. Muse is polite. It asks before it buys. Security is the deterministic check, outside the model, that the action doesn't execute unless policy says so.

Part two: Grok

5. Enterprise plumbing, consumer history

On December 30, xAI shipped Grok Business at $30 a seat and Grok Enterprise on custom pricing. The enterprise plumbing is real: SSO, SCIM directory sync, RBAC, audit logging, an admin console, an "Enterprise Vault" with customer-managed keys, and a promise not to train on business data. That checklist will clear a lot of procurement reviews.

Here's the WTF: enterprise-grade identity plumbing attached to a model with a consumer-grade history. Grok spent January in headlines for generating content it shouldn't. In February, researchers reported that assistants with web-fetch capability, Grok among them, could be manipulated into relaying malware command-and-control traffic. Your team is already expensing it; the $30 tier doesn't need a procurement cycle.

None of this makes Grok uniquely dangerous. It makes it a clean case study in the question every enterprise AI tool raises and almost none of them answer: once the agent is authenticated and inside, what decides what it may do?

6. "Permission-aware" isn't "authorized"

Grok Business pulls from Google Drive with what xAI calls permission-aware access: if the user can see the file, Grok can read it. Sounds right. Now look at what it checks and what it doesn't.

What Grok checks: can this user see this Drive file? Is this user in the SSO directory? Did an admin enable the connector?

What nobody checks: should this file reach an external model at all? May this agent act on what it read, and how? Who approved the next action it took?

Permission-aware access is a grant. It inherits a human's entitlements and hands them to a model. Authorization is a decision about each action in context: this principal, this data classification, this destination, this moment. The Cyber60 survey found "agent identity, authorization and access governance" is the #1 category CISOs will evaluate in 2027. This is why. The identity layer is getting good. The decision layer barely exists.

7. The C2 problem

In February, security researchers reported that Microsoft Copilot and xAI Grok could be manipulated to relay command-and-control traffic for malware. The mechanism is the web-fetch capability: an attacker's implant talks to the assistant, the assistant fetches URLs, and the traffic rides out on an allowlisted, TLS-encrypted, fully legitimate AI service. Your detection stack can't flag it. It looks exactly like legitimate AI use because it is legitimate AI use of the tool.

This isn't a Grok vulnerability in the CVE sense, and Copilot was named in the same research. It's a property of any assistant with outbound fetch and a human's credentials. Which is exactly why detection-centric thinking fails and policy-centric thinking holds. A risk score can't resolve "is this legitimate-looking behavior authorized?" A policy can: this principal may fetch these destinations, for these purposes, at this rate, and nothing else. Detection answers "is this unusual?" Authorization answers "is this allowed?" You need both. Only one of them bounds the blast radius.

8. The only question that matters

Swap in Copilot, ChatGPT, Gemini or Claude and seven of these eight sections still stand. The question isn't "should we allow Grok." Your team already answered that with a corporate card. The question is: what decides what Grok may do, per action, inside our systems, and where is the record?

If the answer is "the vendor's guardrails," you've outsourced your authorization policy to a model you don't control. Guardrails are probabilistic, and they live inside the thing being attacked. If the answer is "our IdP," you've answered who, not what. If the answer is "we'd see it in detection," you'd see the anomalous ones; the legitimate-looking wrong ones walk through.

The answer that holds across every vendor: a decision point outside the model, at your resource. Policy as code, versioned and tested like software. Allow, deny, or escalate to a named human. Every decision logged against the policy version that made it, replayable. That's the layer the agent enterprise is missing, and it's what EnforceAuth builds.

The full reference architecture, worked policy example and 10-question self-assessment are in the Cyber60 white paper on the EnforceAuth blog.