Ah, Jordan pointed out that a charm secret behaves the same, and that's true:

```shell
tameyer@tam-canoncial-1:~/scratch/dummycharm$ cat src/charm.py 
#!/usr/bin/env python3
# Copyright 2024 Tony Meyer
# See LICENSE file for licensing details.

"""Charm the application."""

import logging

import ops

logger = logging.getLogger(__name__)


class DummycharmCharm(ops.CharmBase):
    """Charm the application."""

    def __init__(self, framework: ops.Framework):
        super().__init__(framework)
        framework.observe(self.on["some_container"].pebble_ready, self._on_pebble_ready)

    def _on_pebble_ready(self, event: ops.PebbleReadyEvent):
        """Handle pebble-ready event."""
        self.unit.add_secret({"two": "two"})
        self.unit.status = ops.ActiveStatus()


if __name__ == "__main__":  # pragma: nocover
    ops.main(DummycharmCharm)  # type: ignore
tameyer@tam-canoncial-1:~/scratch/dummycharm$ charmcraft pack
Packed dummycharm_ubuntu-22.04-amd64.charm                                                                                                            
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju refresh --path ./dummycharm_ubuntu-22.04-amd64.charm dummycharm
Added local charm "dummycharm", revision 1, to the model
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju add-unit dummycharm
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju secrets
ID                    Name           Owner         Rotation  Revision  Last updated
cpfq9b7mp25c77uu93lg  examplesecret  <model>       never            1  26 minutes ago  
cpfqlgvmp25c77lna7h0  -              dummycharm/0  never            1  14 seconds ago  
cpfqlinmp25c77lna7hg  -              dummycharm/1  never            1  7 seconds ago   
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-get secret:cpfqlgvmp25c77lna7h0
two: two
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/1 secret-get secret:cpfqlgvmp25c77lna7h0
ERROR permission denied
ERROR the following task failed:
 - id "180" with return code 1

use 'juju show-task' to inspect the failure
```

There is inconsistency between secret-get and secret-info-get (and maybe elsewhere), e.g.:

```shell
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-info-get cpfq9b7mp25c77uu93lg
ERROR secret "cpfq9b7mp25c77uu93lg" not found
ERROR the following task failed:
 - id "184" with return code 1

use 'juju show-task' to inspect the failure

tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-info-get cpfqlgvmp25c77lna7h0
cpfqlgvmp25c77lna7h0:
  revision: 1
  label: ""
  owner: unit
  rotation: never
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/1 secret-info-get cpfqlgvmp25c77lna7h0
ERROR secret "cpfqlgvmp25c77lna7h0" not found
ERROR the following task failed:
 - id "188" with return code 1

use 'juju show-task' to inspect the failure

tameyer@tam-canoncial-1:~/scratch/dummycharm$ 

```

But there too user and charm secrets are the same.

I'll re-open the ops bug and open a PR to fix ops. If you want to make the various cases consistent that would still be nice, but the user vs charm case seems to be wrong, sorry. I should have checked the opposite case rather than just relying on the original ops ticket :(