The Thunk.AI platform uses OAuth 2.0/OIDC-based single-sign-on to authenticate user accounts.
In the public multi-tenant instance of the service, the two signon providers supported are Google and Microsoft. If the user's business email is provided by either Google Workspace or Microsoft 365 and the company's admin allows single-sign-on authentication for third-party applications like Thunk.AI, then single-sign-on will work seamlessly.
In a private instance, any suitable OIDC-compatible identity provider can be used for authorization.
This same identity is associated with the user when the AI agent takes any actions acting on the user’s behalf.
All API calls made to Thunk.AI and all agent activity happen in the context of one "thunk" which is a specific workflow application. The thunk definition includes role-based access control. Users of a thunk are listed (via a whitelist) in one of four roles:
Owner: a thunk has a single Owner.
Admins: they are implicitly also Admins. Owners and Admins can add other users to the thunk and modify the access control definition.
Participants: they are assigned steps in individual workflow runs. While their AI agents usually execute the workflow steps on their behalf, the participants can engage in a "human-in-the-loop" fashion, approving or overriding the decisions made by their AI agents.
End-Users: they can submit new workflow requests via the authenticated API. There are no other actions that utilize the end-user identity. In particular, no steps of the workflow run with the identity of the end-user.
Admins and Owners are implicitly also Participants, and members of all roles are implicitly also End-Users.
In many thunks, especially fully automated thunks, the only user is the thunk oOwner who plays all roles.
User Identity during Agent Execution
An earlier article described how AI agents in Thunk.AI run within a control sandbox environment. This is very important to understand when considering user identity. To briefly summarize, every AI agent execution in Thunk.AI is implemented with two components: (a) the AI agent itself, and (b) a sandboxed execution environment that controls and manages the AI agent.
The AI agent always acts with the identity of the assigned participant while the execution environment acts with the identity of the thunk owner. In practice, the identity of the AI agent matters only with respect to AI context and preferences.
However, all interaction with the external world and the business environment (access to data and files or updates) occurs via tool calls executed by the sandboxed execution environment. This would imply that all tool calls are made with the identity of the thunk owner. In short, from the perspective of any external application, the tool invocation activity of a thunk workflow application uses the identity of the thunk owner or whatever credentials (eg: a database username and password) that the thunk owner used to configure the application modules used for the thunk.
This is the default configuration of a thunk. Since tool calls can be restricted in a number of ways (eg: an API call can be restricted to only allow certain parameters or a file system can be restricted to only expose certain folders), this allows a thunk owner to provide just a minimal set of capabilities to participants and their AI agents, without requiring that complex and often unsupported granular access control be implemented on the external business applications.
For a certain class of applications, it may be desirable to force tool calls to execute with the identity of the participants. A common case is when the tool calls access a shared file system (like Google Drive) and there is a desire to use the access control mechanisms of the file system as an additional governance safety net. If this is the desired behavior for a thunk, the admins can enforce this by setting an appropriate option.
Whichever choice is made, each AI agent in a thunk can only access data and perform actions that the appropriate user (thunk owner or participant) is authorized to do. There is no way for an AI agent to enter a more privileged mode or escalate its permissions beyond those of the thunk owner. This strict limitation is hardcoded into our system architecture.
Platform mitigations of common risks
Implement Transitive Authentication: The identity of the thunk owner or workflow participant (based on the thunk security configuration is transitively used for any tools calls that invoke APIs.
Implement Least Privilege Access: The thunk owner/admins can limit the AI tools available to every agent task. By doing so, they control the surface area of available access to external data and resources.
Regularly Audit and Review Access Privileges: Thunk owners should conduct these reviews as part of the recommended development and lifecycle management process.
Platform Monitoring and Logging: The Thunk platform uses Open Telemetry collectors and cloud specific telemetry and monitoring platforms to record, report, and alert on authentication and authorization events. All tool calls are logged along with their parameters and their results