Least-Privilege Camera Access: Real, Talk, PTZ and Playback Are Separate Decisions

#camera #automation

Design least-privilege camera access by giving each sub-account only the documented permission and resource it needs. On Imou Open Platform, Real, Talk, Ptz, and RecordReplay are separate permissions, while resources identify either a device (dev:serial-number) or a channel (cam:serial-number:channel-number). Start narrow, verify the resulting policy, and remove access promptly when the user’s role or device assignment ends.

Why this matters

A person who may watch a lobby camera does not automatically need to speak through it, move it, replay recordings, change settings, format storage, or upgrade firmware. Treating “camera access” as one switch makes reviews difficult and increases the impact of a misplaced credential.

Imou’s sub-account model exists to avoid exposing an administrator accessToken to other users. It lets an application describe permissions and resources in a Policy. Your product still decides which business role maps to which policy; the platform enforces the policy you send.

Turn a job into a policy

Product need	Documented permission	Typical resource scope
View a live channel	`Real`	`cam:deviceId:channelId`
Use voice intercom	`Talk`	`cam:deviceId:channelId`
Move a capable camera	`Ptz`	`cam:deviceId:channelId`
Play cloud or local video	`RecordReplay`	`cam:deviceId:channelId`
Query alarm messages	`Alarm`	`dev:deviceId` or `cam:deviceId:channelId`
Capture an image	`Capture`	Device or channel, as the called interface documents
Change device configuration	`Config`	Device or channel, as the called interface documents
Upgrade a device	`Upgrade`	`dev:deviceId`
Format an SD card	`Format`	`dev:deviceId`

The full documented vocabulary is Alarm, Config, Ptz, Capture, Upgrade, Format, Real, RecordReplay, Talk, and DevControl. DevControl is broad: the documentation describes it as complete device control, including the other currently defined device-operation permissions and later-defined ones. That makes it a poor default for a least-privilege role.

A practical six-step review

Name the one user action. Begin with “view this channel,” not “access this camera.”
Select the matching documented permission. Keep application-role labels in your own identity layer; an Imou policy must use the documented platform permissions.
Choose the smallest resource. Use a cam: resource when the user needs one channel. Use a dev: resource only when device-level scope is intended.
Create or update the policy on a trusted backend. addPolicy requires the sub-account openid, a Policy, and an administrator accessToken. Keep that token and the AppSecret away from browsers and mobile clients.
Verify effective access. Use queryDevicePermission for a device-and-channel view, or listSubAccountDevice to review the resources assigned to the sub-account.
Offboard explicitly. Use deleteDevicePermission, clearPolicy, or deleteSubAccount according to whether one resource, the policy, or the identity relationship is ending.

An illustrative policy can remain small:

{
  "statement": [
    {
      "permission": "Real,RecordReplay",
      "resource": ["cam:DEVICE123:0"]
    },
    {
      "permission": "Talk",
      "resource": ["cam:DEVICE456:0"]
    }
  ]
}

This example expresses two decisions rather than granting a generic camera role. It does not mean every device supports every operation; device capability and the minimum permission stated on each interface page remain authoritative.

Architecture boundary

Layer	Responsibility
Your identity system	Authenticate the user and determine tenant, site, and job role
Your backend	Map the role to an `openid`, permissions, and `dev:`/`cam:` resources
Imou sub-account policy	Enforce access to the described platform resources
Device and service	Determine whether the requested operation is actually available

Limits and pitfalls

Do not hand out the administrator token. It represents the administrator account’s broader device scope.
Do not use DevControl as onboarding convenience. Its breadth conflicts with a narrow default and can include later-defined device-operation permissions.
Do not confuse authorization with capability. Ptz permission cannot add motors; Talk cannot add audio hardware; RecordReplay does not create recordings.
Review device-level grants carefully. A cam: resource belongs to a dev: resource, and documented device permissions can pass to child channels.
Treat removal as a workflow, not cleanup. Role changes, site transfers, and customer termination should trigger policy reconciliation.
Recheck interface pages. The minimum permission and supported resource shown by the specific API are the final source for that operation.

The useful security question is not “Can this user access cameras?” It is “Which user may perform which documented operation on which device or channel, for how long?”

Register at Imou Open Platform to evaluate its cloud-video and AIoT APIs and SDKs, then model each product role as a deliberately narrow sub-account policy.

DEV Community