What changed
FACT: Android 17 (Google I/O '26 announcement, signal 839) lets an app act as an on-device MCP server whose functions OS-level agents call directly instead of driving the UI. INFERENCE: this creates a new callee-side attack/consent surface that the platform ships as all-or-nothing OS trust.
Why now
FACT: the app-as-MCP-server surface only shipped with Android 17, so the callee-side consent/audit layer is genuinely unclaimed whitespace. HYPOTHESIS: first-mover window exists before Google bakes an equivalent broker into the platform SDK.
Converging signals
Two CAPABILITY signals meet: (1) Android 17 app-as-MCP-server surface (android), (2) Microsoft agent-governance-toolkit mapping controls to OWASP Agentic Top 10 (ai). INFERENCE: Microsoft legitimizes the agent-security category but governs the AGENT/cloud identity, not the device-local per-invocation consent broker inside the callee app.
Customer pain
HYPOTHESIS ONLY. No demand_evidence was provided — no complaints, no job postings, no mandate. The pain (an app can't scope/revoke/audit an individual agent's access to its exposed functions) is inferred from the API design, not evidenced by any developer asking for it. This is a solution looking for a not-yet-existent problem.
Who pays
Claimed: Android app developers shipping agent-invocable apps (SDK license) and regulated app publishers needing per-agent auditability. INFERENCE: today essentially zero apps expose MCP tools because Android 17 is brand-new and near-zero-installed-base, so the reachable paying buyer count is ~0 right now.
Solved today
FACT: not solved app-side — the platform offers only all-or-nothing OS trust. Microsoft's toolkit and OWASP guidance address enterprise/cloud agent governance, not on-device per-call consent.
Why current solutions are bad
INFERENCE: all-or-nothing trust gives no scoping, revocation, or audit — a real security gap IF app-as-MCP-server adoption becomes widespread. That 'if' is the entire risk.
Proposed product
An Android SDK wrapping MCP tool registration: local policy engine, optional consent card, short-lived per-tool+args-class scoped tokens, single-agent key revocation, and an exportable tamper-evident signed audit ledger. Sample app exposing 3 gated tools.
MVP version
Drop-in library + sample app with 3 broker-gated MCP tools, a consent UI, per-agent key revocation, and an exportable signed audit log — buildable in weeks against the Android 17 API.
30-day build
Build the SDK + sample app against Android 17. Run the founder's own kill test: put it in front of 5 developers actually shipping (or planning) agent-invocable apps and see if any will gate their tools behind it.
60-day build
If ≥3 of 5 want it, harden the ledger/attestation and publish an open-source core with a paid pro tier. If not, KILL — the thesis is falsified.
90-day revenue plan
HYPOTHESIS: SDK license / support to a handful of early adopters. Realistically revenue is unlikely inside 90 days given near-zero installed base of Android 17 agent apps.
Distribution path
Developer channels: GitHub, Android dev forums, r/androiddev (note: Reddit ingestion blocked from server but reachable manually), Google I/O agent-API early-adopter community.
Pricing hypothesis
Open-core: free SDK core, paid pro/audit/attestation tier or per-seat SDK license. HYPOTHESIS — no evidence of willingness-to-pay yet.
Technical difficulty
Moderate-to-high: cryptographic attestation, token minting, tamper-evident ledger, policy engine, all against a brand-new unstable API. Outside the founder's core strengths (public records, compliance filing, operational tools).
Legal / regulatory risk
Low. No licensure required to ship an SDK.
Platform dependency
HIGH and decisive: the entire product is a thin layer on one vendor's brand-new API. Google can bake an equivalent broker into the platform SDK and zero the product overnight — the founder's own kill test names this. This is textbook platform_policy_risk.
Founder fit
Weak-to-moderate. Bridges android+ai but it is a security-primitive developer SDK — not a government-portal filing tool, complaint-mined operational tool, or public-money flow. No forced buyer, no reachable paying class, no evidence of demand. Sits OUTSIDE the founder's proven edge and primary theses.
Breakout potential
HYPOTHESIS: real IF on-device agent-to-app MCP becomes ubiquitous and Google does NOT ship its own broker — a big, unproven double conditional. Patent on the per-invocation scoped-consent-token mechanism could matter, but the founder does not want speculative multi-year plays.
Final recommendation
WATCH / REVISIT LATER, do not build now. Interesting invention and genuine whitespace, but it fails the right kill reasons: no evidenced buyer, near-zero installed base, and severe first-party platform-displacement risk. Log the Android 17 agent-API trend and re-check in 2-3 quarters; if app-as-MCP-server adoption is real AND Google has NOT shipped its own broker, reconsider. Prioritise mandate/public-money and complaint-backed opportunities instead.
Next action
Run the founder's own cheap kill test before any real build: pitch the concept to 5 developers shipping Android 17 agent-invocable apps; only proceed if ≥3 will gate their tools behind it. Otherwise shelve and revisit next quarter.