Scoped Agent Identity

Because a shared credential erases exactly the information you need when something goes wrong: which workflow did this. If every agent acted through one master key, disabling a problem workflow would mean disabling everything behind that key, or nothing, since there would be no way to isolate just the misbehaving piece. A shared login also means a wrong write cannot be traced to the specific job that caused it, only to "the integration" in general. Giving each agent its own identity, the same pattern used in agent-identity models like Microsoft Entra Agent ID and Salesforce Agentforce's per-agent permission sets, avoids that by making the workflow, not the credential, the unit that gets scoped, logged, and revoked.

The permissions attached to each agent are set to what that specific job needs and nothing past it. An agent that logs call activity against a record holds contact and activity scopes; it does not hold delete access or billing scopes, because its job never calls for them. That limit is enforced in the platform, in OAuth scopes, permission sets, and object- or field-level security, not inside a prompt asking the model to behave. The distinction matters because a system instruction telling an agent what not to do is a request that assumes the instruction is followed; a token that was never granted the permission in the first place is a control that holds regardless of what the agent is told or how it is manipulated.

Because each agent has its own identity, every entry in the audit trail is keyed to a specific, named actor rather than a generic "system" account. That is what makes precise reversal possible: if one workflow starts producing bad writes, every change it made can be identified and rolled back as a set, while writes made by other agents and by humans are left untouched. Without that separation, undoing a bad run means guessing which of many unattributed changes actually came from the misbehaving piece, which turns a clean rollback into a manual audit.

Because access is scoped and independent per agent, revoking one does not touch the others. Pausing the workflow that creates Jira tickets, for example, has no effect on the workflow drafting CRM updates or the one flagging renewal risk, because each holds its own credentials and its own permission set rather than sharing a single connection that everything depends on. That independence is also what makes pausing or canceling a workflow a clean action rather than an all-or-nothing switch, consistent with how the subscription itself works: there is no minimum term, and pausing one active workflow does not require unwinding every integration at once.

Left alone, any system that accumulates access tends to accumulate more of it than it uses, a pattern generally called scope sprawl. The corrective is a periodic review: compare what each agent identity is permissioned to touch against what it has actually used, and cut the difference. Because every agent is scoped to one job rather than sharing broad access with several, that comparison is tractable, one identity maps to one workflow, so a review does not require untangling which of many jobs a single shared credential is actually being used for.

No, the two are complementary controls that answer different questions. A scoped identity limits what an agent is even capable of doing, an agent without delete access cannot delete a record no matter what it is asked to do. The approval gate limits what a capable agent is allowed to do without a human confirming it first. Least privilege bounds the blast radius if something goes wrong; the approval gate catches the specific instance before it happens. A workflow that is heavily scoped but has no approval step can still make a wrong stage change within its allowed scope; a workflow with a strong approval gate but broad scope is one bad approval away from a much bigger mistake. Both controls have to hold at once.

A new hire can be trained, can ask a question when something looks off, and can be held accountable in ways that create natural friction before a mistake happens. An agent has none of that: it acts at machine speed on the instructions and context it is given, and it can be steered by what it reads, a misleading line in an email or a manipulated document, in ways a person generally is not. That difference is why agent permissions cannot lean on the same informal trust a human employee's access does. The scope has to be enforced mechanically, in the platform's own permission system, because there is no equivalent to a new hire pausing to double check something that looks wrong.

No, because reads and writes are scoped differently on purpose. An agent can read broadly across the tools it is connected to, pulling context from a CRM record, a related ticket, or prior call notes, so its drafts are grounded in the full picture rather than a narrow slice. The scoping described here applies specifically to writes, the fields and objects an agent is permitted to change. That asymmetry is intentional: a wide read path lets an agent make a well-informed proposal, while a narrow write path keeps what it is actually allowed to change small and known, so being well-informed never translates into being able to touch more than the job requires.