The October 29 Play policy announcement is mostly the usual paperwork. But one line in it made me stop and read twice.
AppFunctions — the thing that lets your app expose actions to AI agents — now has its own enforcement clause. Google's wording, and I'm paraphrasing only a little: developers building AppFunctions must not deceive or manipulate AI agents, bypass security controls, or interfere with other applications.
The agents are real customers now. And Google is writing rules for how my app is allowed to talk to them.
Let me back up, because a lot of Android developers I've talked to have only a vague idea what AppFunctions actually is. I'm Artem Garazha, an Android developer from Ukraine. I've been shipping Android apps for years, and lately I've spent a lot of time thinking about what happens when my apps stop being opened by human thumbs and start being called by software.
What AppFunctions is, without the marketing
AppFunctions is Google's mechanism for letting your app expose discrete, structured actions that something else can invoke. Not push notifications. Not intents in the old sense, where a tap on a link opens your activity. A catalogue of functions: "book a table," "check the weather for Kyiv," "restart the thermostat."
An AI agent — on-device or otherwise — can read that catalogue and decide to call one of your functions. It passes structured arguments. Your app runs the function and returns a result.
The important part: the agent decides. Your app is not in charge of the conversation. It's a tool the agent reaches for, the same way it might reach for a calculator or a web search.
The new rule, read closely
Here's the actual language from the October 29 announcement:
AppFunctions are strictly prohibited from deceiving or manipulating AI agents, bypassing security controls, or interfering with other applications.
Three separate things, three separate problems.
Deceiving an AI agent means lying to it in your function's metadata or its return values. Describing a function as "read-only" when it actually writes. Returning a price when you know the real price is higher. Claiming a capability you don't really have so the agent routes to you instead of a competitor.
Bypassing security controls is the one that worries me most, because it's easy to do by accident. If an agent could get a user or the operating system to grant a permission, and your function instead works around that, you've just shipped a policy violation.
Interfering with other applications covers the darker stuff: eating another app's agent traffic, spamming the agent with fake results, poisoning the shared context it builds from multiple apps.
None of this is a surprise if you think about it. There are already rules against deceiving users and apps. All Google did is extend the same logic to a new kind of caller.
Why now
Because the agents arrived before the rules did. The first wave of AppFunctions integrations treated the agent as a novelty. The second wave treats it as a user acquisition channel, which is exactly when the bad actors show up.
I got an early taste of this myself. My retro camera app got AppShortcuts wired up so it could answer voice-agent prompts about the phone's camera. Once it was live, the first thing I noticed was how tempting it is to make your function look more capable than it is. Describe it a little too broadly, and the agent will route you questions you can't answer. Answer them anyway, and you're lying.
The line between marketing and deception is thin when your "customer" is a model doing string matching on your own description.
What I'm actually doing about it
I'm not going to wait for enforcement to find me. A few concrete things I'm doing now:
First, I'm auditing the exact text of every function description I've shipped. The description is what the agent sees. If it says more than the function does, I rewrite it until it doesn't.
Second, I'm making return values boring. Unembellished data, no confidence levels I can't back up, no "I looked at everything" when I looked at a cache.
Third, and this is the part I keep coming back to: I'm treating the agent the same way the policy already treats a human user. No dark patterns, no half-truths, no pretending a capability exists. The same bar, just applied to a caller that can't get annoyed and leave.
An agent can't roll its eyes when you waste its time. That's exactly why the rules need to be written down.
You can find me on YouTube at the Pin Up Retro Manner channel where I demo the apps I build, and on Instagram, where I post shorter updates about what I'm working on.
The bottom line
If you expose AppFunctions today, read that October 29 announcement. Not the summary. The actual language.
Treat your function descriptions like UI copy. They're not internal docs anymore. They're a contract with a caller that will route real users to you based on what you claim.
And if any part of that description is a lie, in the new rules that's no longer a marketing problem. It's a policy violation.
Top comments (0)