Google just announced AppFunctions — a framework that lets Android apps expose their capabilities directly to AI agents. Instead of opening Uber and tapping through screens, you tell Gemini "get me a ride to the airport" and it calls the function directly.
Google's own blog post says it: AppFunctions mirrors how "backend capabilities are declared via MCP cloud servers." This isn't a coincidence. It's the same pattern — tools exposed to AI agents via structured function calls — applied to mobile.
And it has the same security gap.
What AppFunctions actually does
Two things are happening here:
1. Structured function exposure. App developers annotate their code with @AppFunction, declaring what their app can do — search photos, book rides, create reminders. AI agents discover these functions and call them directly. The app never opens. The user never sees a UI.
2. UI automation. For apps that haven't adopted AppFunctions, Google is building a framework where Gemini can operate the app's UI autonomously — tapping buttons, filling forms, navigating screens. No developer integration needed. The AI just drives the app like a human would.
Both are live on Galaxy S26 and Pixel 10 devices today.
The MCP parallel
If you work with MCP (Model Context Protocol), this will feel familiar:
| MCP | AppFunctions |
|---|---|
Server exposes tools via tools/list
|
App exposes functions via @AppFunction
|
Agent calls tools/call with arguments |
Agent calls function with parameters |
| Runs on desktop/server | Runs on-device |
| Claude, Cursor, Windsurf | Gemini |
Google explicitly acknowledges this — they call AppFunctions the "on-device solution" that mirrors MCP cloud servers. Same architecture, different runtime.
What's missing
Google says they're "designing these features with privacy and security at their core." Here's what they describe for safety:
- Users can monitor task progress via notifications
- Users can switch to manual control
- Gemini alerts users "before completing sensitive tasks, such as making a purchase"
That's it. No policy engine. No per-function access control. No rate limiting. No argument validation.
The security model is: trust the agent, notify the user.
If you've worked with AI agents in production, you know why this is concerning. Agents don't always do what you expect. They hallucinate. They misinterpret instructions. They chain actions in ways nobody anticipated. And prompt injection — where a malicious input hijacks the agent's behavior — is a solved problem exactly nowhere.
What "trust the agent" looks like in practice
Consider what's exposed via AppFunctions today: Calendar, Notes, Tasks, Samsung Gallery. Benign enough. But Google says they're expanding to food delivery, grocery, and rideshare next — and opening it to all developers in Android 17.
Now imagine AppFunctions on:
- Banking apps — "transfer $500 to this account"
- Email apps — "send this email to my entire contact list"
- Enterprise apps — "export all customer records"
- Payment apps — "send money to..."
Each of these is a function call. And the only thing standing between the agent and execution is... a notification? A prompt that says "are you sure?"
We've seen this movie before. Claude Code deleted 2.5 years of production data last week. Not because it was malicious — because it misunderstood an instruction and had unrestricted access to destructive tools.
The pattern that's actually needed
The fix isn't to trust agents less or give them fewer capabilities. AppFunctions is the right direction — structured, discoverable, typed function calls are better than screen scraping. The fix is to add an enforcement layer between the agent and the function.
In MCP, we built Intercept to solve exactly this. It's a transparent proxy that evaluates every tool call against a YAML policy before forwarding it:
tools:
send_money:
rules:
- name: "cap transfers"
conditions:
- path: "args.amount"
op: "lte"
value: 10000
on_deny: "Transfer exceeds $100 limit"
delete_account:
rules:
- name: "block deletion"
action: "deny"
search_photos:
rules:
- name: "rate limit"
rate_limit: 20/minute
The agent never sees these rules. It can't negotiate around them. They're enforced at the transport layer — deterministic, not probabilistic.
This is the pattern AppFunctions needs. Not "alert the user before a purchase." A policy engine that lets users and enterprises define exactly what agents can and can't do, enforced mechanically, not by asking the agent to behave.
Why this matters beyond Android
Google isn't alone. The same pattern is appearing everywhere:
- MCP — Anthropic's protocol for tool access (desktop/server)
- AppFunctions — Google's protocol for tool access (Android)
- WebMCP — Google's protocol for tool access (Chrome)
- AWS Bedrock AgentCore — Amazon's agent gateway (cloud)
Every major platform is building a way for AI agents to call functions. None of them have shipped a standard enforcement layer. They're all building the gas pedal and leaving the brakes to someone else.
That someone else is what we're building at PolicyLayer. Intercept works at the MCP layer today. The architecture — transparent proxy, deterministic policy, transport-layer enforcement — is protocol-agnostic. The same pattern applies to AppFunctions, WebMCP, and whatever comes next.
What should happen
Three things need to exist before AI agents operate our apps at scale:
1. Declarative policies. Users and enterprises need to define rules — not in natural language, not as prompts, but as structured, auditable policy files. "This agent can search photos but can't send messages." "Transfers are capped at $100." "No more than 5 actions per minute."
2. Transport-layer enforcement. Policies must be enforced below the model context. The agent shouldn't know the rules exist, shouldn't be able to reason about them, and definitely shouldn't be able to override them.
3. Audit trails. Every function call, every policy decision, logged in structured format. When something goes wrong — and it will — you need to know exactly what happened.
Google will probably build some of this into Android eventually. But waiting for platform vendors to solve security after shipping capability is how every major vulnerability in computing history has played out.
The enforcement layer needs to exist independently of the platform. That's what open-source infrastructure is for.
We're building Intercept — an open-source enforcement proxy for AI agent tool calls. It works with MCP today, and the architecture applies to any agent-to-tool protocol. Check it out on GitHub.
Top comments (0)