Your identity provider (Microsoft Entra ID)
Human identity
- Signs in with MSAL and PKCELive
- Bearer JWT to the API, validated against JWKSLive
- Permission check on every routeLive
- Personas at organisation or space scopeLive
SECURITY & GOVERNANCE
Autonomy needs
clear authority.
Build security decisions into the lifecycle. Define who and what can act, the evidence required, and the people accountable when conditions change.
AN EXPLICIT CONTROL MODEL
Every action crosses
a boundary.
Make the boundary visible before the action happens.
01User intent
Identity & purpose
02Agent policy
Scope & approval
03Tool permission
Allowed operation
04External system
Constrained access
Illustrative control model. Place review and enforcement at the boundaries that matter to your workflow.
AGENT IDENTITY & DELEGATION
Who acted, on whose behalf,
under which policy.
An agent action carries a chain of identities. Each link keeps the scopes it was delegated, so the answer to “who did this” is a record, not a guess.
PKCE sign-inBearer JWT · permission check
Registered in Catalog with an owner
Agent identity
- Owner, status and specification recordedLive
- Workload identity per agentDesigned
- Acts on behalf of a user, or as itselfDesigned
Delegated / workload identityScopes carried, not copied
Registered with transport, scopes and owner
MCP identity
- Servers, gateways and authorizers syncedLive
- Scopes recorded per serverLive
- Delegated scopes from the agentDesigned
Delegated or app permissionsLeast privilege per tool
The permission the target actually sees
Tool / API identity
- Policy statement permits or denies, enforced or log-onlyLive
- Read-only role in your customer accountLive
- Delegated (on behalf of) or app permissionsDesigned
01Who initiated02Which identity acted03On whose behalf04Which scopes05Which policy06What happened
Live today: human identity via Entra sign-in (MSAL with PKCE), a bearer JWT to the API, a permission check on every request, and a read-only role in your accounts. Designed: agent identity and delegated scopes to MCP servers and tools.
DESIGN · RELEASE · RUNTIME
Security is a continuous practice.
Authority with boundaries
Distinguish the requesting user, executing agent, and connected tool. Define the scopes each action needs and the actions that require approval.
REVIEWABLE EVIDENCE
Identity map · permission inventory · approval rules
Threats tied to the workflow
Review untrusted instructions, tool misuse, sensitive information, poisoned context, and unexpected recovery paths against the actual design.
REVIEWABLE EVIDENCE
Threat register · control owner · verification evidence
Evidence at release
Trace each criterion to a versioned evaluation result, review decision, or an explicitly accepted exception.
REVIEWABLE EVIDENCE
Evaluation matrix · release record · exception conditions
Your repositories stay yours
Coding runs commit as your engineer and open a neutral pull request into your repository. An attribution lint is a hard gate before publish, and a named reviewer merges; the Coding Expert never merges.
REVIEWABLE EVIDENCE
Attribution lint · pull request · reviewer merge
Bounded autonomy
Each coding run works in one isolated session in the platform account within limits set per space: budget, turns, duration and concurrency. Deploy tokens are scoped per space, held in memory for the run and redacted from events.
REVIEWABLE EVIDENCE
Space limits · coding run record · redacted events
Response during execution
Connect observed behavior to the relevant permission, policy, and operational owner. Record the action taken and the remaining risk.
REVIEWABLE EVIDENCE
Execution trace · event record · containment decision
Context under control
Define where knowledge comes from, what an agent may retain, who can access it, and when retained information should expire.
REVIEWABLE EVIDENCE
Source provenance · access policy · retention rules
Governed change
Bring changes to tools, skills, models, memory, and the harness back through the appropriate review before promotion.
REVIEWABLE EVIDENCE
Change record · updated evaluations · owner approval
TENANCY
One platform account.
Your accounts stay read-only.
Crescendent runs in one platform account per enterprise, deployable in your cloud account; AWS today. It hosts the platform and its base agents, the Coding Expert and the Regulatory Watch.
Your runtime accounts are connected as read-only inventory; nothing runs there. Coding runs execute in the isolated runtime of the platform account and push a branch and pull request back to your repository through a per-space token. Deploying what is built to the platform runtime follows on the roadmap. The control model is runtime-agnostic: the same identities, policies and evidence apply whichever runtime hosts the agent.
See how a coding run worksTHE AGENT EVIDENCE GRAPH
Know why an agent
is allowed to act.
Requirement, agent, MCP server, tool, policy, evaluation, approval and deployment are linked records. The reasoning stays available when the workflow changes. Runtime trace joins the graph on the roadmap.
- 01Requirement
Why the agent exists
- 02Agent
Owner, status, specification
- 03MCP server
Transport, scopes, owner
- 04Tool
Permitted operation
- 05Policy
Permitting statement, enforced or log-only
- 06Evaluation
Cases and results
- 07Approval
Named approver, decision
- 08Deployment
Release to the runtime
- 09Trace (roadmap)
Runtime behaviour (roadmap)
Example question
“Why was Agent X allowed to call CreatePurchaseOrder yesterday?”
- UserWho initiated the request
- AgentWhich agent record acted
- Delegated identityOn whose behalf it acteddesigned
- MCP serverWhich server exposed the tool
- ToolWhich operation was permitted
- PolicyWhich permitting statement applied
- ApproverWho approved the permission
- RequirementWhich requirement motivated it
- EvaluationWhich cases proved the behaviour
- ReleaseWhich deployment carried it
- TraceWhat actually happened at runtimeroadmap
Release decision recordExample
CHANGE REVIEW AGENT / RELEASE 0.3
Ready for owner review
IntentDraft changes; require approval to apply
AccessRead project · propose patch
EvaluationExpected, boundary, and failure cases
RecoveryResume from reviewed checkpoint
Decision owner: release lead
Live links today: requirement → design decision → access boundary → implementation → evaluation → approval → deployment. Runtime trace: roadmap.
REGULATORY KNOWLEDGE & POSTURE
Know which rules apply,
with the evidence behind them.
A registry of regulations, guidance, standards and frameworks, searchable with cited passages, and a proposed risk posture for each agent, skill and MCP server.
Each assessment names the applicable instruments with citations and the tiers per framework (EU AI Act, NIST AI RMF, 21 CFR Part 11, GxP impact, data sensitivity), and maps each identified risk to controls whose status and evidence are recorded. A posture stays proposed until a named person approves it. The tiers are the platform's proposed mapping approved by that person, not a legal determination; the platform records mappings, posture and evidence, and never asserts that an asset meets a regulation.
Explore Cresc. ComplianceEVERY RUNTIME, READ-ONLY
Your runtimes stay yours.
The control model is the same.
Runtimes are connected as read-only inventory; nothing runs there. The platform records what is deployed, by whom and with which evidence.
Available today
Amazon Bedrock AgentCore
Read-only inventory of agents, runtimes, gateways, MCP tools, memory and policy engines; deployments recorded with their evidence.
Next
Azure AI Foundry
The same read-only sync and deployment records for agents hosted in Azure.
Designed for
Heterogeneous agent estates
Frameworks, clouds, MCP ecosystems: one control model, runtime-agnostic.
How you buy itAWS MarketplaceRoadmap Subscribe and buy through AWS Marketplace with your existing AWS agreement; annual contracts and private offers. Roadmap.
START READ-ONLY
Start with a 14-day
estate assessment.
Grant a read-only role, see your whole agent estate, and decide the first bounded workflow with evidence in hand. Nothing runs in your accounts.