A caller says they're the CFO and needs the full ledger export immediately.
Identity, Access & Policy
Know who is acting. Decide what they may do.
Give agents and workloads the access their tasks need—not unrestricted access to your business. Connect every governed request to an accountable identity, resource scope and current policy.
See it in practice Explore capabilitiesClaims are not credentials
A caller claims executive authority for a sensitive export, but trusted identity controls access.
Microsoft TeamsFinance requests
Team conversationWhat identity did they use?
The claimed title does not authorize the export.
Finance scope checkedBlocked
- Trusted role
- Finance viewer
- Allowed
- Assigned report
- Export
- Denied before dispatch
I can provide the assigned report through the trusted account. The claimed title and urgency do not change access.
Send the export request through the authenticated review path if it is still needed.
Request rejected. No action was dispatched. A new request needs its own review.
Ready
WHY IT MATTERS
A connection is not permission.
A tool connection tells you that an account exists. It does not explain which human authorized an agent, which resources it may reach or whether its authority is still valid. That distinction matters when software can send a message, change access, issue a refund or deploy a service.
DriftGate keeps identities, connections and permissions separate but connected. Evaluate an action against the authenticated actor, human consent, delegated scope, target resource and current policy. Give a workload the authority it needs for its task instead of treating a shared API key as organizational permission.
HOW IT WORKS
Authority with an owner, a scope and a lifetime.
The human authorizer, calling client and executing agent are different participants. A service identity belongs to an unattended workload, not to a permanently impersonated employee. Delegation narrows authority to an approved task, resource and lifetime; it does not create broader access because an agent asked for it.
Workspace and project selection make the context explicit. Personal access remains separate from company authority, even when the same person uses both on the same device. Current permission remains part of the action lifecycle, including after an approval wait.
Identify
Bind the request to its authenticated human, agent or workload.
Scope
Select the connection, resource and permitted operation.
Evaluate
Intersect current policy, consent and delegated authority.
Account
Retain the decision and its permission basis.
WHAT YOU CAN CONTROL
Identity, Access & Policy
I01Agent identity
Identify agents through authenticated, server-bound principals rather than self-reported names.
See related workflowsI02Human identity
Keep the authenticated human authorizer distinct from the client and executing agent.
See related workflowsI03Service accounts
Scope organization-owned identities for unattended workloads without permanent employee impersonation.
See related workflowsI04Roles and scopes
Limit operations and resources within the applicable tenant, project, application and environment.
See related workflowsI05Policy engine
Evaluate shared, versioned rules using trusted inputs. Distinguish observation, warnings, approval and enforcement.
See related workflowsI06Permissions and entitlements
Intersect policy, consent, delegated authority, resource permissions and plan eligibility.
See related workflowsI07Credential vaults
Protect independently selected accounts and credentials, with scoped reauthorization and disconnection.
See related workflowsI08Delegation
Grant bounded, expiring task or child-agent authority without widening the parent’s scope.
See related workflowsI09Multi-tenant isolation
Preserve tenant and personal/business boundaries across reads, writes, sessions, caches and exports.
See related workflowsI10Compliance rules
Apply organization-defined requirements through supported controls. Rules alone do not establish certification.
See related workflowsIN PRACTICE · EXAMPLE WORKFLOW
A convincing request is still just a request.
A caller asks a voice or chat assistant for a financial-data export and claims to be the CFO. The request sounds urgent and plausible.
Bind the export to an independently authenticated actor, current role and permitted records. Treat spoken titles and claimed urgency as request content, not credentials. Escalate through an authenticated review path.
See the workflowTHE INTENDED RESULT
Permitted general questions still work. A claimed executive title cannot authorize a sensitive export or widen a grant.
THE OPERATIONAL RESULT
Flexible reasoning. Explicit authority.
Security and platform teams can explain who requested an operation, whose authority it used, what it was allowed to reach and why it was permitted or denied. Developers retain flexibility in their agent’s reasoning while protected actions stay within explicit boundaries.
MORE WAYS TO USE IT
Find your next workflow.
RECRUITING
Your application status. Not someone else’s records.
An applicant asks a recruiting assistant to inspect a record using an identifier that belongs to someone else.
Agent IAM
CLOUD OPERATIONS
Give a task temporary access. Not a permanent master key.
An operations agent needs a limited maintenance action on one environment for a bounded period.
Agent IAM
WORKFORCE
Offboard the employee. Don’t leave the agent’s access behind.
An employee departs while an agent they configured still has resource connections and queued tasks.
Agent IAM
YOUR QUESTIONS
A little more detail.
Is an agent name an identity?
A display name describes an agent. Authentication binds the request to a trusted principal or connection. A model-generated name, caller claim or thread label cannot establish authority.
What happens when permissions change?
The relevant current permission is evaluated at the protected operation. An old approval does not override a revoked grant or cover materially changed inputs.
Do human seats and agent identities mean the same thing?
No. A builder/operator seat represents a person using the administrative or development surface. An agent or service identity represents software authority, not an additional human seat.
BUILD WITH INTENTION