Academy
5. Grants: Giving @oupi the Right Capabilities
Configure per-device and per-group grants so missions can dispatch work to the device while keeping the default sovereign posture for the rest of the fleet.
By default, every Nexus One in your fleet starts in a fully sovereign posture: nothing is granted to @oupi, and no mission can dispatch work to any device. Grants are the mechanism you use to change that, selectively. You grant specific capabilities — read anchors, run skills, produce artifacts — to @oupi on a per-device or per-group basis. Until you explicitly open a grant, the device is invisible to missions. This lets you keep most of your fleet locked down while enabling exactly the devices (or groups) that need to participate in automated workflows.
Grants work hand-in-hand with anchors. Anchors define where on the device missions may read and write (specific folders you expose). Grants define what @oupi is allowed to do with those anchors and with the device's other capabilities. A grant without anchors means @oupi can run skills but has no file access. Anchors without a grant mean the folders are exposed but no mission can reach them. You need both pieces configured for a mission to dispatch file-related work to a device. Add or remove either from the device console at any time — changes take effect immediately.
Device groups (e.g., "Workshop", "Site A") let you manage grants in bulk. Instead of configuring each device individually, assign devices to a group and set grants at the group level. Every device in the group inherits those grants. This is essential when you scale beyond a handful of devices: you maintain a consistent security posture across a site or function, and onboarding a new device is as simple as adding it to the right group. You can still override grants on a single device when one machine needs different permissions.
Start narrow: grant only "read anchors" on a single test device first. Confirm that missions can reach the expected folders and return results. Then layer on "run skills" and "produce artifacts" once you trust the workflow. Scaling to a group afterward is one click.
Remember that remote access is off by default and is separate from grants. Enabling a grant does not open a remote tunnel. If you also need to reach the device from outside, enable remote access explicitly per device — it is protected by your OUPI login.
Open "My connections", select a paired Nexus One, and open its console. Create or choose a device group, assign the device to it, then grant @oupi the "read anchors" capability on that group. Verify that at least one anchor (folder) is exposed. Check that the grant appears active in the console.
Grants control what @oupi can do on each Nexus One — read anchors, run skills, produce artifacts — and can be set per device or per group. The default is fully sovereign (nothing granted). Anchors define the folders in scope; grants define the allowed actions. Use groups to manage permissions at scale, and always start with the narrowest grant that satisfies your workflow. Remote access is a separate toggle. All changes are instant and revocable from the console.