How should AI agents handle your location, and other people's location?

ChatGPT Use cases and examples
1

I’ve been building PositionGuard, a privacy-first presence platform, and I’ve recently connected its MCP server to ChatGPT. Now I’m looking for a few MCP/AI developers who are willing to try it, poke holes in it, and help me think through what the right consent model should look like.

PositionGuard isn’t about sharing exact locations or tracking people. It provides area-level presence, enough context for useful things like:

“You’re at the grocery store, can you pick up some milk?”

or:

“How many people are at the pickleball court?”

The interesting problem isn’t simply giving an AI access to your location.

When an AI agent gets access to your personal data, it may also get information about other people like family members, friends, colleagues, or anyone who has shared information with you.

So who gets to decide whether the AI can see that information?

PositionGuard takes a different approach: each person controls whether their presence can be shared with AI assistants, while existing area-level privacy controls still apply. The MCP server then enforces those permissions when an agent asks for information.

I’ve been testing this with a simulated family and ChatGPT. For example, if one family member has enabled AI sharing and another hasn’t, the agent can distinguish between confirmed presence and unknown rather than assuming that missing information means someone is absent.

PositionGuard is still in development, and I’m looking for people who are interested in helping me test it. Particularly developers working with MCP, ChatGPT, Claude, Dots, or other AI agent platforms.

If you’re interested in testing the MCP server or discussing the authorization and consent model, comment here or DM me and I’ll share the details.

2

So with ChatGPT you actually have location sharing controls already, and it’s off by default, see here. It sounds like a more interesting problem is actually getting the shared location of family members (or “the circle”) into ChatGPT. So effectively if a service like Life360 enabled ChatGPT integration. And then you control location sharing options via Life360 and ChatGPT.

So am I correct to understand you are introducing a third surface area here, which is, assuming you have some family location service already, and you are exposing that to an agentic system, you sit in between and provide another layer of access control?

3

Thanks for the thoughtful response, and for sharing the link , that’s a useful reference.

Yes, you’re very close to what I’m exploring.

The important distinction is that PositionGuard is the presence engine, not simply an access-control layer added on top of another location service.

PositionGuard already has the concepts of groups, members, areas, and per-member/per-area visibility. The underlying idea is to turn location signals into useful presence information without exposing exact coordinates or continuously tracking people.

For example, the system can know that someone is at the grocery store, gym, home, or pickleball court without the AI needing to know their exact location.Life360 is a useful reference point, but my focus is less on competing with location-tracking products and more on exploring what user-controlled presence could look like when AI agents enter the picture.

What I’m experimenting with now is extending that existing consent model to AI agents through MCP.

So a family member can decide that their presence can be shared with an AI assistant, while another member can choose not to share with AI. The agent doesn’t get the underlying location data and then make that decision itself, the MCP server enforces the permissions before returning anything.

That creates an interesting situation that doesn’t really exist with a typical single-user AI integration: the person asking the AI the question may not be the person whose data is being returned.

For example:

“Who is home?”

The answer could include one family member whose AI sharing is enabled, while another member remains unknown because they haven’t consented to AI access. The system should never interpret unknown as absent.

That’s actually the part I’m most interested in getting feedback on: what should the consent and authorization model look like when an AI agent can ask questions about multiple people, rather than just the person who connected the service?

The overall architecture is in place; I’m now working through the MCP authorization model and looking for people to test it and challenge the assumptions.

4

Interesting problem. Unknown not being absent is the right call. A few things I’d pressure-test:

  1. Consent per subject per client, not just “AI on/off”. Someone might be fine with their partner’s Claude asking “who’s home” but not a work agent connected by the same account. If consent is tied to the person asking and the client ID from your OAuth flow, you can revoke one without the other.

  2. Counts leak individuals. “How many people at the pickleball court” with 1 or 2 people there, plus “is X out”, tells you where X is. I’d have a minimum count below which the answer is “a few” or unknown, applied before the numbers leave your server.

  3. Show subjects who asked. A per-person log of which agent asked about them and what it got back makes consent something people can check, and it’s what you’ll want when someone says “I never agreed to that”.

  4. Treat what comes back as untrusted on the agent side. Presence answers end up in the model’s context, so keep them structured (state + area + freshness) rather than free text the model might act on.

Happy to test it. If you can share the server repo or config, I can also run agent-audit-kit on it (open source, runs offline). It checks MCP auth and config gaps like OAuth 2.1 / RFC 9728, not the consent logic itself

5

Thanks, this is exactly the kind of pressure-testing I’m looking for.

The consent-per-subject-per-client distinction is particularly interesting. PositionGuard already has a fairly granular presence and visibility model at the member, group, and area level, so I’m thinking about how that should extend into the AI authorization layer rather than creating a parallel privacy model. It’s something I definitely want to account for in the architecture even if the first version doesn’t expose every dimension of it.

As a first step, you can install PositionGuard and play with the presence model. It’s available on iOS and Android; the Android version is currently in early access on Google Play.

I’m working on a more scalable version of the hosted MCP server now so that multiple people can connect and test it with their own AI assistants. The public self-hosted MCP repo and the Muse integration are useful for developers who want to experiment on their own, but for this particular experiment I think the more interesting thing is the hosted MCP service and its authentication/authorization model.

I should have it available for testing soon. I’ll follow up here when it’s ready, hopefully within the next few days, assuming I don’t run into anything unexpected.

I’d definitely be interested in having you test it and run your audit tooling against it once it’s ready. And I really appreciate the thoughtful input here. This is exactly the kind of feedback I was hoping to get.

::