Where your data lives#
Eido Build runs in your Azure subscription. Everything it stores is in the SQL database the installer created there: work items, documents, conversations, decisions and attachments. One backup of that database restores a working system.
Your code stays in your repository host. Eido Build works on it through the connection you set up, and agents work on a copy in a sandbox.
No shared secrets#
Nothing in an installation is a password, client secret or API key that both sides hold.
| What | How it proves who it is |
|---|---|
| People signing in | An app registration in your tenant, used only to sign people in. It has no secret or certificate. |
| The database | Microsoft Entra only. Eido Build’s own managed identity is the database’s administrator. |
| Key Vault, storage, container registry | Eido Build’s managed identity, with roles given by the installer. |
| Updating itself | Eido Build’s managed identity, which may deploy to its own App Service and nothing else. |
| Microsoft Graph, for Windows 365 | Eido Build’s managed identity, with permissions an administrator grants only if Windows 365 is wanted. |
| Licensing | Check-ins signed with a key the installation made itself. |
What Eido Build’s identity may do#
| Where | Role |
|---|---|
| Its own App Service | Website Contributor |
| Its resource group | Reader |
| Key Vault | Key Vault Secrets User |
| Storage account | Storage Blob Data Contributor, Storage Blob Delegator |
| Container registry | Contributor |
| Application Insights, Log Analytics | Monitoring Reader, Log Analytics Reader |
| Foundry, if installed | Foundry Project Manager, Foundry User, Foundry Account Owner |
Who can do what#
Everything in Eido Build needs a signed-in user. Permissions are checked by Eido Build on every request, not only by hiding buttons. See Users and permissions.
Odie has no account of its own. Anything Odie changes is done by the person who pressed the card, with that person’s permissions.
Agents and credentials#
An agent cannot be given a credential.
- To call another system, an agent is granted a specific action. Eido Build makes the request and adds the credential on its own side. See Integrations for agents.
- Inside a sandbox, the agent has no repository token. Eido Build adds it to git’s requests from outside the agent’s reach.
- An agent with read-only code access works with a token that can only read, so the repository host itself refuses a push.
- On a Foundry workbench, model calls go through a proxy, so the agent does not hold a model credential either.
Every action call is logged, including the ones that were refused.
Where models run#
| Workbench | Where your code and prompts go |
|---|---|
| Foundry | Models deployed in your own Azure AI Foundry project, in your tenant. |
| Anthropic | Anthropic’s platform, under your own Anthropic API key and agreement. |
You choose per project, per stage and per agent. See Workbenches.
What is sent to Eido#
Only the licence check-in: the install id, the version, and counts of users, projects, work items and agents. None of their content is sent. See Licensing.
Links and pasted content#
When Odie or an agent fetches a link, Eido Build makes the request and refuses private network addresses. Text pasted into Odie is treated as something to read, not as instructions.
Scripts#
Project actions run on the Eido Build server. Only admins can write them, and every run is logged with who ran it.