Governance & Guardrails
Set the access, compliance, and security boundaries your agents operate inside before they reach production.
Agents act on your behalf against your systems and your data. This page covers the boundaries you set around that.
The Outcome
Your agent system has a defined blast radius - who can reach it, what it can touch, and what evidence exists that it is compliant.
Before You Start
Governance is configured in Application Management, which becomes available once an application exists. You can set it before or after deployment, but the controls below should be decided before the agent handles real data.
Bring whatever the assessment surfaced: if the Gap Mitigation Plan flagged compliance gaps, they get closed here.
Start Here
Decide your trust model first, because everything else depends on it.
In Identity & Access, you choose between:
- Trust whoever calls - simplest, appropriate for internal or low-risk agents
- Check every caller - token verification against your identity provider
If the agent touches regulated or personal data, this is not a real choice. Pick caller verification.
Access Control
| Control | What it sets |
|---|---|
| Trust model | Whether callers are verified against your IdP |
| Group access | Named groups and what each group can reach |
| SSO Connections | Microsoft Entra ID, Google Workspace, Okta, Auth0, SAML, OIDC |
| Directory Sync (SCIM) | Auto-provision and deprovision users from your corporate directory |
| Domain Verification | Which email domains your users may sign in from |
| Sign-in Policy | MFA requirements and session timeout rules |
| Grants | Scoped access grants for users and agents |
| Agent Auth | Service principal credentials so agents authenticate as trusted identities |
Directory Sync matters more than it looks. Without SCIM, deprovisioning is manual - someone who leaves the organization keeps agent access until a human remembers to revoke it.
Compliance Evidence
The Compliance & Security tab generates the artifacts an auditor or DPO will ask for:
| Sub-tab | What it produces |
|---|---|
| Security | On-demand pen testing via AWS Security Agent, findings as a downloadable PDF |
| Compliance | DPO Pack - seven GDPR documents generated in parallel (Privacy Policy, Data Flow Map, Security Policy, Retention Policy, Subprocessor Register, Cookie Policy, GDPR Controls) |
| WAFR | AWS Well-Architected Framework Review across six pillars |
| Design Document | Application design document covering architecture, data models, and API contracts |
These are generated artifacts, not certifications. They are a strong starting position for a review - they are not a substitute for one.
Sequencing
Run these in order:
- Trust model and access - before the agent sees real data
- Pen test - after deployment, before opening access beyond the build team
- DPO Pack - before processing personal data
- WAFR - before scaling to a second use case, so findings inform the next build
What Good Looks Like
- Trust model chosen deliberately, not left at default
- Deprovisioning is automated through SCIM, not a manual step someone must remember
- A pen test has been run against the deployed agent, and findings are either fixed or consciously accepted
- If personal data is involved, the DPO Pack exists and someone has actually read it
Where This Leads
With boundaries set, move into Launch and build inside them - see Agentic System to configure agent roles and tools, and Test Bed to run safety and stress tests before deploying.