An assistant that can create a task, edit a document, and update a public request board needs a credential wide enough to reach all three surfaces. That same width is where a request can land on the wrong target instead of the one the person actually meant.
Dutify’s AI Coworker sits in exactly this spot. It runs in Slack or Teams, watches a conversation, and turns pieces of it into tasks in Dutify Cloud, edits in Codexum, or updates in Roadmarq, sometimes inside a single exchange. To do any of that, it needs a credential that already reaches all three products before it has read the message deciding which one actually applies.
Security researchers have a name for what goes wrong when a program holds more authority than a specific request needs, and gets misdirected into spending that authority on the wrong target: a confused deputy. The deputy isn’t compromised. It can’t tell a resource the requester meant apart from one that merely matches the description it was given, and its credential lets it touch either.
Keeping that gap closed takes three things staying attached to every write an assistant makes: who actually asked for it, which resource they meant, and which credential carried out the action. Lose track of any one of those and the same failure opens back up under a different name.
A collision that doesn’t need malice
Suppose a workspace has two projects called Launch, because one is this quarter’s release and the other is a stale copy a contractor set up last year and never renamed. Someone asks AI Coworker in Slack to log a bug against the Launch project. If the credential behind that request can already reach every project the person has access to, deciding which Launch is correct falls entirely on the assistant’s read of a short message, not on anything the credential rules out on its own. Guess wrong, and the bug lands in a project nobody on the release team is watching, filed under an identity that looks like an ordinary task creation.
The same shape shows up outside Dutify Cloud. A Codexum space and a Roadmarq board can share a name with something the requester didn’t mean, and an assistant with account-wide reach into both has no structural reason to prefer one over the other. In Roadmarq specifically, the wrong board can be the one that mirrors onto the public roadmap page customers already have bookmarked, so a status update meant for an internal triage board becomes visible to anyone watching the public one.
A record of what happened doesn’t stop it happening
Once AI Coworker writes something, you can usually reconstruct who typed the original message and which text the assistant matched to a project. That reconstruction answers a different question than the one that mattered at the moment of the write. It tells you afterward that a bug landed in the wrong project. It doesn’t shrink what the assistant’s credential was able to touch in the first place, because that credential was scoped to everything the requester could personally reach, not to the one project they meant. Someone on the release team has to notice the bug is missing before that reconstruction ever runs, and that can take days if the wrong project isn’t one anyone watches closely.
Narrowing that has to happen earlier, before the assistant ever reads the message, in what the credential is allowed to touch to begin with.
What the credential is actually allowed to touch
A personal API key issued to AI Coworker has historically inherited the requesting user’s own permissions across Dutify Cloud, Codexum, and Roadmarq. That made sense when a person held the key and decided, call by call, exactly which resource they meant. Once an assistant is resolving that decision from a Slack message instead, the same shape of key hands it the same reach a person has, without the judgment a person applies before typing.
On September 13, Dutify Cloud shipped resource-scoped API keys that narrow this further: a key can now be bound to one specific project inside Dutify Cloud, one space inside Codexum, or one board inside Roadmarq, instead of everything those products expose to the account holder. Point AI Coworker at a key scoped to this quarter’s actual Launch project, and an instruction that would have resolved to the stale copy has nowhere to go. The credential itself doesn’t reach it, regardless of what the assistant’s text matching would have guessed.
That protection only extends as far as the scope is drawn. A key scoped to an entire workspace still lets a resolution mistake land on any project inside that workspace. A key scoped to one project doesn’t.
What scoping closes, and what it leaves open
Of the three things that have to stay attached to a write, identity was never the weak point. A personal API key issued to AI Coworker already belongs to one member of the workspace, and a workspace key is bound to one named member when it’s created. Whichever Launch project a bug lands in, the write still carries the identity of the person who typed the Slack message, the same way it did before September 13.
The credential’s reach changed that day. Reading the message and deciding which project, space, or board it points to is still the assistant’s job, and that judgment can still be wrong. A key scoped to one project means a wrong guess has nothing to write to outside that project, because the credential doesn’t reach outside it either. The assistant isn’t reading the message any more carefully than before. A wrong read now fails instead of landing somewhere real.
That’s a meaningful change for a workspace with two stale Launch projects: the assistant’s wrong guess used to be able to write to either one, and now it can only reach the one the key was scoped to. It stops mattering the moment a key is scoped to cover more than one project, because the same ambiguity is still live inside whatever boundary the key allows.
Where a wiki space makes the stakes visible
The same boundary applies beyond Dutify Cloud, where a wrong guess carries different stakes. A Codexum workspace routinely holds a dozen or more spaces side by side: an internal engineering runbook next to onboarding notes next to a space that’s already published as a public docs site or help center. Those aren’t just folders. Each one can have a different audience on the other side of it.
Suppose “add this incident writeup to the wiki” could resolve to either the internal engineering space or the space already mirrored out to a public help center, because both cover the same product area and the wording doesn’t settle which one is meant. If AI Coworker’s key reaches the whole Codexum workspace, that ambiguity has a real cost: a writeup meant for engineers can land in the space a public URL already points to, and the mistake is live the moment the page saves, not after someone happens to notice. A key scoped to the internal space specifically keeps that write inside it no matter how the request was worded, the same way a project-scoped key keeps a task inside the project it was meant for.
The fix here isn’t a judgment the assistant has to get right on every message. It’s a boundary set once, when a key is created for AI Coworker or any other integration, that decides what the assistant is even capable of touching if its guess is wrong. That boundary lives in the same API key settings across Dutify Cloud, Codexum, and Roadmarq, and it doesn’t depend on a text match holding up every single time.