Action Security Model

Ground Truth

No users can execute outside the scope of the credentials and permissions that admins and data owners have explicitly granted.

Quick Definitions and Answers

• Invoking an Action: Prompting an Agent to decide that an Action should be taken.
• Executing the Action: Running the Action using your permissions/scopes.
• Which user-level providers can I OAuth into?: All by default. Admins can prevent shadow IT connections to non-approved sources that happen to be supported by Credal by disabling those actions in the “Admin data sources” tab.
• Who can invoke actions?: Users defined in End User Access configuration in Action Deployment.
• Who can execute actions?: Approvers. If there are no approvers, invokers.
• Where are actions invoked?: In requests made to Agents that have permission to use the Action, as defined in Agent Access configuration. End User Access to these Actions applies transitively.
• How do we infer resource level access for org-wide no perm providers and arbitrary webhooks?: Admins can vet certain groups/users as executors of the action. No one else can configure these granular access settings.

Action Connection Type Table

---

¹ End User Access list: This refers to the list of users explicitly defined in the Action Deployment configuration who are permitted to invoke the Action.

² Trusted Allowlist: If HITL enabled, it’s set of approvers, else it is set of end users with access - trust the admin publishing to verify this is correct

³ Admin only edits: Until we have version control for Actions, this will require an admin user for changes to prevent unauthorized behavior changes to published actions.

Multi User Operations

An operation is a multi-user operation if the approval to carry out a given action in the workflow is someone other than the sender. Credal has HITL approval mechanisms that you can configure to use your credentials or permissions scopes in a cross-functional or multi-user operation. A request that is not initiated by you can only use credentials/scopes if you give explicit permission to do so.

Approval flow

• If you provide approval for an Action, you are allowing Credal to use your credentials to carry out that one specific action. Your credentials are granted for only that action, and any further use must go through your explicit permission.
• The guard-rails that already exist in the underlying systems remain the ultimate source of truth; Credal just adds a programmable, fully-logged wrapper on top. Credal never manufactures new privileges out of thin air and is simply automating the same approval you would have done manually (like a ping in Slack or a tap on the shoulder)—except now with a perfect audit trail.
• For these workflows, the approver—not the requester—is on the hook in the audit trail.
• If permissions enhancement takes place anywhere in an Agent, that agent cannot be deployed to end users by anyone other than a Credal admin.

Considerations when permissions are enhanced in a request

• The “write” Actions are typically void and don’t bring in sensitive information into the chat history, but the “read” Actions pose DLP risks. Note: We do not recommend expanding access permissions in Agents directly available to end users, rather you should use Agent-to-Agent handoffs for this (see below). Nonetheless, the below features and considerations make multi-user requests airtight in Credal.
• Let’s say you need to fetch specific sensitive data from a database to answer an employee’s yes/no/etc. question, but they are not allowed to see the raw underlying data. There are a few risks associated with permissions enhancement when automating these sorts of Enterprise operations.
  • A user seeing the sensitive retrieved information in the context window which is visible to participants of the conversation.
    • In order to properly manage when your credentials are used, we strongly recommend creating separate agents for each user role involved in the operation. The user-facing agent can then handoff requests to the Agent that will perform sensitive read operations under an approver’s credentials. If a conversation is deemed to be sensitive, end users will not be allowed to view them as the context windows may contain sensitive data used to derive responses. Only the approvers and whomever they share the conversation with can view it.
    • If you choose to escalate permissions in a conversation between an end user and an Agent, any retrieved data from an action will be redacted from the conversation context window and will only be visible if viewed by the approver.
  • Adversarial prompt injection (user asking for something they shouldn’t be)
    • For fields associated with user identity, Credal will assign caller-set parameters to hard code the sender’s email, user ID, requesting agent ID, etc. This will guarantee that Bob can’t ask for Mary’s salary information, for example.
    • Caller set parameters are not considered credentials, so an approver’s metadata is not used as the caller set parameters, it will always be the original sender.
  • Mistakes the agent makes or indirect leakage through summaries (hallucinations and implied information)
    • All Actions in an Agent that undergo permission escalation must have the Action Release Gate turned on. If a builder wants to turn it off for whatever reason, there must be a justification provided with that toggle off. The ARG will require an egress approval step from the Agent owner(s). This way, humans can use their expertise and judgment to ensure DLP.

All three of these provisions together make your multi-user workflows airtight and prevent any unauthorized access, visibility, or indirect leakage.