Governance
AI safety
How Flexday AI keeps Agents and the Builder within bounds - explicit grants, guardrails, blocked topics, grounding, budgets, evaluations and citations.
Written for
- Everyone
- Functional users
Last reviewed
AI models are powerful and fallible. Flexday AI does not rely on the model alone: the limits that matter most are enforced in code. What an Agent may do is a list you grant. What it may be asked is checked before the model sees it. When personal-data masking is on, what it answers is masked again afterwards, and every turn is recorded, budgeted and measurable.
At a glance
- The boundary is a list, not a prompt. An Agent can use only the tools you grant it, inside its own Solution. No wording in a message can widen that.
- Checks run before the model. Rate, length, blocked patterns, personal data and blocked topics are checked before the Agent's model sees a message (topics described in words by one fast classification), and a blocked message never reaches it.
- Answers you can check. Citations name the retrieved documents an answer's wording matches, and grounding tells an Agent to search before it answers, with one reminder if it does not.
- Enforced budgets. Every turn has budgets for tool calls, tokens and time, under platform ceilings, enforced by the engine between steps.
- Tested before release. Evaluations can be required to pass before a new version is published.
Controls around an Agent
| Control | What it does |
|---|---|
| Tool grants | An explicit allow-list of ten kinds of capability. A grant that reaches a resource names it, and everything it names is checked to be in the same Solution when a session starts. |
| Input guardrails | Checked cheapest first: rate, length, blocked patterns, personal data (block, mask or warn), keyword topics, meaning-based topics, then optional moderation. |
| Blocked topics | Subjects checked before the Agent's model runs: a keyword by exact match, a topic described in words by one fast classification. Block refuses; Flag lets the conversation continue. A described topic can also start a Flow either way, for example to alert HR. A flagged topic is never announced to the person it is about. |
| Untrusted content | Tool results and retrieved documents are marked as untrusted, and the Agent is instructed to treat anything inside them as information, not orders. The grant list still limits what it can do. |
| Grounding | Answer only from connected knowledge: the Agent is told to search its sources before stating a fact about your business, and is reminded once if it answered without looking. |
| Budgets | Per turn: tool calls, output tokens and time, checked by the engine between steps. At 80% the Agent is told to wrap up; at 100% it gets no more tools and gives a short final answer. |
| Output guardrails | When personal-data masking is on, personal data is masked again in the reply and in the stored transcript. An output format, when the Agent has one, is requested and checked, with retries. |
| Outbound calls | HTTP calls must start at an allow-listed address prefix, no hop (redirects included) may reach a private network, and stored credentials go only to the original host. An Agent sends at most one email per turn, under the Solution's email rules. |
| Human handoff | An Agent can end the session for a person to follow up, and the recipients you list are emailed the details. No one takes over the chat. |
| Secrets | An Agent can never read a Secret Variable. |
Testing and previewing
- Evaluations. Golden test cases with assertions (text, pattern, JSON schema, tool use, call and token caps, and a model-scored rubric) run against the real engine. Publishing can require the default set's latest run to have passed on the current draft.
- Preview as. Workspace owners and admins can test a turn as if they held a chosen set of audience tags, in the Playground or in a live app's chat. Anything that would send, write, run a Flow, call out or delegate is refused while previewing.
- Analytics. Real use only: volumes, people, tools, sources, guardrail events and feedback.
Controls around the Builder
| Control | What it does |
|---|---|
| Same services as people | Every tool goes through the same validation, audit trail, versions, quotas and Solution boundary as Studio. |
| Deterministic checks | Recurring model mistakes are caught and repaired by code, not by another instruction to the model. |
| Finish gate | When the Builder declares the work finished, the app's read queries are wired into its gateway and app calls that point at nothing are reported; it may set that report aside when it does not apply, never the wiring. It cannot finish while something you asked for that only the platform can build is neither built for real nor declared as a placeholder. An unmet "Done when" item refuses the finish once, and the result is shown to you as met or not met. A turn that ends on a question or a plain reply does not run the gate. |
| Plans before changes | A schema change is planned first and applied exactly as planned, once; the Builder is told to describe the plan in the chat, but it does not wait for approval. |
| What it changes on its own | Schema changes, data loads, saved queries and gateway endpoints apply as the Builder makes them, and it can publish the Flows and Agents it builds. App files wait in the Draft: it never deploys an app after the first build, and never switches a Flow on. Replacing rows a live app writes to needs your request or your yes. |
| Hold means hold | "Don't build yet" is enforced: while a hold is in place, every tool that would change something is refused. The Builder is also told to answer questions about what exists without changing anything. |
| No secrets | The Builder's tools never hand a stored secret to the model: a Connection's credential and a secret Variable's value are never shown to it. Anything typed into the chat reaches the model, so enter credentials in the Studio's forms. |
Delegation between Agents
An Agent can hand a task to a specialist Agent. The specialist runs one isolated turn under the original caller's access (it can narrow that access, never widen it), cannot ask the person anything, and returns only its answer. The whole conversation turn shares one allowance: 4 specialist calls in total, at most 2 separate delegations running at once, and chains of Agents and Flows 3 levels deep.
What stays your responsibility
- Choosing which tools and knowledge an Agent is granted.
- Writing instructions, blocked topics and evaluations that reflect your policies.
- Reviewing Agent analytics and conversations, and acting on flagged topics.
What an evaluator can verify
| To confirm | Where to look in a trial |
|---|---|
| That an Agent can use only what it is granted | The Agent's Tools tab lists every tool and what it reaches. In the Playground, ask it to do something it has no tool for: it cannot. |
| That guardrails run before the model | The Guardrails tab: personal-data handling, rate and length limits, blocked topics, blocked patterns and moderation. Send a message on a blocked topic in the Playground: it is refused before the model answers. Guardrail events from real conversations appear in the Agent's Analytics. |
| That evaluations can gate publishing | The Evals tab holds the evaluation sets; on the Instructions tab, Require evals to pass before publishing turns the gate on. Change the draft and try to publish without a passing run. |
| What an end user would see | In the Playground, an owner or admin can preview as an end user with chosen audience tags. |
| That the Builder declares what it did not build | A Solution's Overview lists anything still a placeholder under Not built for real yet. |
