Governed Enterprise Agent Runtime

Why this matters: once an agent acts under its own identity and runs on triggers, the risk is no longer a wrong answer. It is a wrong action. This package gives a Spring Boot team a runnable control plane where every agent action has a named identity, an accountable owner, a policy decision, a human approver for high-risk steps, governed memory, and a hash-chained evidence record you can export and verify.

Problem

The shift is not "more features". Agents are becoming process participants

On October 15, 2026, Microsoft announced three Copilot Studio capabilities: agent accounts, business process memory, and triggers. They are rolling out in stages through the Frontier program and in preview, with prerequisites, licensing requirements and documented limitations. Taken together, they say more than any one feature does:

• With an agent account, an agent gets its own Microsoft Entra identity, mailbox and presence in Microsoft 365. In supported Teams, Outlook and Office scenarios, people can mention it or assign it work, and it acts with its own scoped permissions.
• Business process memory carries context across cycles of a shared process instead of resetting every conversation.
• Triggers let an agent start on its own, from an event or a schedule.

Microsoft describes further access policies, quality and cost management, and agent lifecycle controls as plans for the coming months. They are not available today.

The point that matters: an agent is moving from "a tool one employee calls" to "a digital participant the organisation owns and delegates work to." When the role changes, the standard an agent is judged by has to change too. "Can it finish the task?" is no longer enough. An enterprise also has to ask:

• Who is acting, and whose permissions is it using?
• Who owns this agent's goals and limits?
• Which actions can run automatically, and which need a human signature?
• What does it remember, who can see that memory, and for how long?
• If a step fails halfway, will a retry run the action twice?
• Afterwards, can we prove what happened, to an auditor and not only to the developer?

This is the line between an agent demo and an agent in production.

Why borrowed credentials do not scale

Most agent pilots run on the developer's token or a shared service account. That breaks in predictable ways:

• Over-permissioning. The agent inherits everything the human can do, not just what its job needs.
• Blurred accountability. Actions are logged against the requester, the builder or a shared account, never against the agent itself.
• Fragile lifecycle. When the person leaves, changes role or rotates credentials, the process breaks without warning.

A separate identity does not grant permissions automatically. It is the foundation that least privilege, separation of duties and lifecycle management can be built on.

Memory is a governed asset, not a chat transcript

Enterprise agents handle three very different kinds of information:

| Kind | Examples | Where it belongs | |---|---|---| | Authoritative facts | Policies, orders, contracts, master data | The system of record. Never replaced by model memory | | Process context | Open issues, exceptions handled, last review's comments, handover notes | Governed process memory, kept across cycles | | Personal preferences | Report format, notification channel, terminology | User-scoped memory with explicit privacy limits |

Shared memory is not finished once it is stored. Each entry needs a source, a scope, a retention period, and a way to view, correct and delete it, plus a record of every time it was used. Microsoft's current preview documentation for agent accounts says plainly that shared memory has no privacy boundary between users. That is exactly why memory governance has to be a core design decision and not a settings toggle.

Triggers turn "wrong answer" into "wrong action"

An agent that runs on events or schedules no longer waits for a human to confirm each step. Long processes meet timeouts, duplicate event delivery, partial success and failing dependencies. Production systems need idempotency keys, retry limits, checkpoints, compensation actions, pause/resume, and human takeover. The more autonomous the agent, the clearer its approval thresholds and fail-safe behaviour must be.

Solution Overview

Six capabilities to treat as first-class

| Capability | The question it answers | What it takes to implement | |---|---|---| | Agent identity | Who is acting? | A dedicated principal per agent, credentials from env/vault, least-privilege tool scopes, rotation | | Process owner | Who is accountable for goals and limits? | A named owner, a business scope, suspend and handover procedures | | Policy & approval | Which actions may run automatically? | Tool risk tiers, a policy engine, human approval, two-person review for the highest tier | | Memory governance | What is remembered, for whom, for how long? | Source, scope, expiry, view/correct/delete, sensitive-data redaction, usage log | | Durable execution | How do we resume safely after failure? | A state machine, idempotent triggers, bounded retries, checkpoints, compensation, human takeover | | Audit evidence | How do we prove what happened? | An append-only, hash-chained event log; input/output digests; tool calls; approvals; versions |

The product decision behind this package: build these as one control plane, not as pieces spread across prompts, connector settings and application logs.

Reference architecture

Event / schedule / human delegation
        │
        ▼
Trigger intake (idempotency key)
        │
        ▼
Identity & policy gateway ──► scope check · risk tier · run budget
        │
        ▼
Durable agent runtime ──────► tools & enterprise systems
        ▲   │
        │   ▼
Governed process memory
        │
        ▼
Human approval / exception takeover
        │
        ▼
Business result + exportable, verifiable evidence pack

This is a vendor-neutral, Spring Boot-native implementation of that control plane. It does not depend on Copilot Studio or Microsoft 365. It is the governance layer you need whichever agent builder or model you choose.

Pilot scenario: a supplier onboarding agent

The package ships with one concrete, deliberately limited shared process, chosen because identity, permissions, shared memory, approval and audit all show up in a single flow, and the agent is never given final decision authority:

1. Trigger. A new supplier application arrives (event, delivered at least once).
2. Identity. The agent reads only the documents its own principal is scoped to.
3. Memory. It consults governed memory about this supplier, for example a previous application that was withdrawn after a beneficial-ownership request, and records a new process note at the end of the run.
4. Approval. A sanctions-list hit or a bank-details change stops the run in WAITING_APPROVAL. A sanctions hit needs a compliance approver. A bank-details change needs two distinct approvers, and neither may be the agent's owner or the requester.
5. Execution. The agent reads the documents, screens the supplier and proposes activation or the bank-details change, then sends a notification. It never grants the final approval itself: the policy denies any direct write to the supplier master.
6. Evidence. Every source read, policy version, tool call, human decision and final output is recorded in a hash chain and can be exported per run.

The failure paths are part of the demo, not only the happy path. A redelivered event creates no duplicate side effects. A suspended agent is refused on its next call, and the refusal is audited. A deleted memory entry is no longer retrievable.

What you get

• A complete, runnable project: Java 17, Spring Boot 3.3, PostgreSQL 16, Flyway, Docker Compose
• An agent principal and owner model, a YAML policy engine with risk tiers, and approval gates with two-person control
• A durable run state machine with idempotent triggers, a transactional outbox, bounded retry and compensation
• Governed process memory with source, scope, expiry, redaction, deletion and an access log
• An append-only, hash-chained audit log, a chain-verification endpoint, and per-run evidence pack export
• Seed data for the supplier onboarding scenario, plus an evidence script that replays the approval, redelivery, revocation, memory-deletion and audit-tamper paths against the running stack and fails if any of them misbehaves
• Implementation notes in the standard order, from architecture to extension points

Verification & Evidence

This package is verified by running the stack with the provided config and seed data, and capturing the evidence pack from the live run: startup health, a real trigger request and response that stops in WAITING_APPROVAL, a database proof of run state and the audit hash chain, and the test summary. Supplementary evidence from the same stack covers duplicate-event redelivery, dual approval with separation of duties, memory deletion, agent revocation, and per-run evidence export with a refused audit-tamper attempt.

What to test next. If your team can already make an agent call tools, the next thing to prove is not another demo. It is identity isolation, approval checkpoints, memory deletion, failure recovery and audit evidence. Related runnable packages:

• Agentic Workflows: idempotency and durable runs
• Self-Healing Agents: failure detection and recovery policies
• LLM Observability with OpenTelemetry and Langfuse

Sources: Microsoft Copilot Blog · Give your agent an account (Frontier) · Memory (preview) · Add triggers to an agent (preview). Microsoft capability statements reflect preview documentation as of publication. Everything under "Solution Overview" is Exesolution's own architecture, not a Microsoft feature.