Skip to content

How your access is protected

Where your access to another app actually goes

Section titled “Where your access to another app actually goes”

The AI model never gets your access to Slack. That’s the promise this whole design exists to keep.

When the AI decides something needs doing in Slack, it asks Tallyfy’s own server to do it. The server asks Tallyfy Vault for a short-lived key, uses it to make the call to Slack as you, and hands back the result. The AI gets the answer. It never gets the key.

Where your access to another app actually goesAI modelTallyfy serverTallyfy VaultSlack Do this for JaneAsk for accessShort-lived tokenAct as JaneResultResult, no token

What to notice

  • The token exists on two legs of this trip and nowhere else.
  • The long-lived half of your sign-in, the part that can fetch a fresh key, stays inside Vault and never appears on this diagram at all.
  • The AI gets a result. It never gets a credential.

The short-lived key goes to Tallyfy’s own server and expires. The long-lived half stays in Vault.

Neither reaches the AI, and neither turns up anywhere you’d later read: not in the AI’s view of what a tool returned, not in a log, not in an error, not in a trace of a request. When something fails, Vault sends back its own plain error rather than passing along whatever Slack said, because raw replies from another app can carry a secret inside them.

A connection belongs to the person who signed in, and it’s granted to your organization so the AI can use it while acting as that person. It’s never a shared robot account.

Personal is the default. An admin can promote a connection to Shared so colleagues can use it, and that takes an explicit acknowledgment first, because a Shared connection means the AI acts through your sign-in for somebody else.

Every request into Vault is checked three ways. Tallyfy has to know which person and which organization is asking. Your organization has to be on a paid plan. And the request has to belong to a real signed-in session.

After that, any of these stops the work outright:

  • The connection is missing.
  • The access has expired.
  • Someone revoked it at the other app.
  • Your organization’s encryption key is locked, or has been destroyed.

Stopping means stopping. Vault won’t reach for a different connection, and it won’t quietly use somebody else’s. You get a task asking you to sign in again instead of silent work done under the wrong name.

Your organization can hold its own encryption key. Admins can rotate it, and there’s a kill switch that destroys it and makes your organization’s stored sign-ins unreadable. See bring your own encryption key for how that works and what it costs you.

Every touch of a credential and every admin action writes an audit record against your organization, with no secret material in it. Refusals and blocked attempts are recorded too, so an attempt to poke at something shows up for your security people even though the person doing the poking learns nothing.

Admins get a usage view under Settings then Connections, showing how much each app and each person is calling, how many calls worked, how many failed, and the state of every connection. It holds counts. It never holds a token.

Your organization’s database inside Vault is encrypted as a whole, and your sign-in sits inside it as a value that means nothing on its own.

There’s a further layer planned that would encrypt each stored sign-in separately, on top of the database encryption. It isn’t built yet. Either way, the AI never receives your access and nothing secret is written to a log.

Vault > Connect an app

Connect an app to Tallyfy from Settings then Connections, so Tallyfy AI can work in that app as…