2 ms·

Curious about the security model here. Giving an agent access to SMS, contacts, and the ability to send email from my phone is a pretty large capability surfac

Curious about the security model here. Giving an agent access to SMS, contacts, and the ability to send email from my phone is a pretty large capability surface — what's the approval flow look like? Is it per-tool-call, per-session, or do you grant broad scopes up front? The MCP tool-use pattern where everything gets pre-approved feels risky for something like "send email," and I'd be interested to know how you're thinking about the difference between "agent reads my calendar" and "agent sends an email as me.

Bridgexapi 6mo ago
this is exactly where it gets tricky once you give something the ability to send messages or trigger actions, it’s not just read access anymore, it’s execution on your behalf it looks simple from the outside, but there’s usually a lot of hidden behavior underneath (routing, timing, provider handling, etc) so the question becomes less about access and more about how controlled and observable that execution actually is curious if you’re thinking about exposing that layer, or keeping it abstracted away
- caihongxu 6mo ago
  [dead]
azmz 6mo ago
[flagged]
caihongxu 6mo ago
Good question. I think of it as scope control + action control. Scope control: in Palmier, you explicitly enable/disable phone capability groups in the UI. Some are bundled according to Android’s permission model. So an agent only gets access to the categories you’ve chosen to expose. Action control: for agent CLIs that already support tool-level permission checks, Palmier piggybacks on that. So even if, say, email/calendar access is enabled in Palmier, the actual tool use can still be approved per action by the agent runtime. So Palmier is one layer of defense, and the agent’s own tool approval model is the second. That means the safety story is much better for agents with good per-tool approval UX (like Claude Code), and weaker for agents that don’t have it (like OpenClaw). For those, the Palmier toggles are the main gate, so users need to be much more careful about what they enable. Any thoughts/suggestions?

Bridgexapi 6mo ago

this is exactly where it gets tricky once you give something the ability to send messages or trigger actions, it’s not just read access anymore, it’s execution on your behalf it looks simple from the outside, but there’s usually a lot of hidden behavior underneath (routing, timing, provider handling, etc) so the question becomes less about access and more about how controlled and observable that execution actually is curious if you’re thinking about exposing that layer, or keeping it abstracted away

caihongxu 6mo ago
[dead]

azmz 6mo ago

[flagged]

caihongxu 6mo ago

Good question. I think of it as scope control + action control. Scope control: in Palmier, you explicitly enable/disable phone capability groups in the UI. Some are bundled according to Android’s permission model. So an agent only gets access to the categories you’ve chosen to expose. Action control: for agent CLIs that already support tool-level permission checks, Palmier piggybacks on that. So even if, say, email/calendar access is enabled in Palmier, the actual tool use can still be approved per action by the agent runtime. So Palmier is one layer of defense, and the agent’s own tool approval model is the second. That means the safety story is much better for agents with good per-tool approval UX (like Claude Code), and weaker for agents that don’t have it (like OpenClaw). For those, the Palmier toggles are the main gate, so users need to be much more careful about what they enable. Any thoughts/suggestions?