Agent Operations Need Scoped Visibility, Permission, and Memory Boundaries

Three verified developments sharpen the boundary between giving agents useful operational context and giving them unsafe access. Agno v2.8.5 introduces eight tools through which an agent can inspect AgentOS metrics, traces, schedules, evaluations, components, and pending approvals. Two research papers address adjacent governance failures: one separates what an agent can technically do from what it is allowed to do, while the other demonstrates that per-user memory isolation does not stop a malicious tool from extracting persistent memory.

The sources do not establish a complete governance system. Agno’s evidence is project-authored and its “read-only” surface includes direct database access and a derived metrics write. The autonomy paper proposes a governance framework and describes one enterprise application without establishing broad comparative effectiveness. The memory-extraction paper reports strong attack results under its evaluated threat model, but those percentages should not be generalized beyond the tested systems and assumptions.

Operational visibility is itself an authorization surface

Agno v2.8.5 (opens in a new tab), supported by merged PR #9185 (opens in a new tab), adds AgentOSTools: eight agent-facing operations tools covering platform metrics, run activity, tool activity, evaluation history, schedules, runtime components, and pending approvals. The implementation groups trace and span statistics by agent, team, workflow, or endpoint and excludes several sensitive payload classes, including span attributes, approval arguments and context, and schedule inputs and outputs.

The release is a material competitor signal because it makes operational telemetry directly queryable by an agent rather than reserving it for a human dashboard. The implementation also documents the trust boundary clearly. These tools read the database directly, so endpoint scopes do not govern their reads. Pending approvals expose identifiers. Postgres metrics retrieval can refresh derived metrics before returning them, meaning “read-only” describes the exposed tool operations rather than an absolute no-write guarantee. Agno recommends limiting the operations agent to operators or disabling individual surfaces for broader audiences.

The pull request reports 66 new project-authored tests and a live check against a running platform database. Postgres and SQLite implement the new grouped statistics, while 14 other backends accept the grouping parameter but do not implement non-default groupings. SQLite returns no p95 duration. A review also found that raw exception text could leak database details to the agent; the correction was incorporated through PR #9188 (opens in a new tab) before release.

For governed agent systems, observability should be treated as a scoped capability. An agent may need metrics and approval status without receiving unrestricted visibility into principals, traces, or operational topology. “No mutation tool” is useful but does not replace audience controls, data minimization, principal binding, or a durable record of who queried which surface.

Allowed autonomy should remain below capability

Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels (opens in a new tab) distinguishes an agent’s Autonomous Capability Level from its Allowed Autonomy Level. The authors describe five stages spanning reactive execution, decision support, supervised action, goal-directed autonomy, and delegated operational authority. Their central claim is that technically capable systems can and often should be constrained to a lower operational level based on risk, reversibility, oversight, accountability, and organizational readiness.

The paper says it applies the framework to a deployed enterprise data-engineering agent. That example is relevant because it makes authorization a separate deployment decision rather than an automatic consequence of model or agent capability. The source is an arXiv v1 preprint submitted on July 26, 2026. Its public abstract does not establish a controlled comparison, independent audit, or general performance result, so the paper should be treated as a governance framework with an illustrative deployment—not proof that the proposed levels reliably prevent harmful actions.

The practical signal is that autonomy labels should not collapse capability and permission into one score. Production governance should record at least the agent’s demonstrated capability, allowed action class, reversibility requirement, approval threshold, accountable principal, and the conditions under which permission is reduced or withdrawn.

Isolated memory can still leak through tools

Isolated but Exposed: Persistence-Based Memory Extraction Attack on LLM Agents (opens in a new tab) identifies an attack path that does not require breaking per-user memory isolation. The paper argues that agents may place long-term-memory content into tool-call parameters, allowing a malicious tool to receive private records through the normal agent interface.

The authors present SPORE, which separates an adversarial command from retrieval anchors, uses tool responses to steer later memory retrieval, and persists reactivation payloads so extraction can resume within and across sessions. The paper reports an 80.0% record-extraction rate with unlimited triggers and 47.0% with 20 triggers. Those are source-reported experimental results from the paper’s threat model, not universal rates for production agents.

The security implication is narrower and stronger than a generic warning about memory: tenant or user isolation at the storage layer is insufficient if retrieved content can flow into an untrusted tool. Persistent-memory governance therefore requires tool trust classification, egress controls, parameter inspection, provenance for retrieved records, bounded cross-session activation, and revocation or deletion mechanisms that apply to both stored facts and persisted attack instructions.

Keelbase Signal assessment

Together, the three records support four separable governance boundaries:

• An observability boundary should determine which operational surfaces an agent can inspect, for which principal, and for what purpose.
• An authorization boundary should keep permitted action below demonstrated capability whenever risk, reversibility, or accountability requires it.
• A memory boundary should control not only who can retrieve stored state, but where retrieved content may flow through tools.
• An evidence boundary should preserve who queried, approved, changed, or disclosed consequential operational state.

For Keelbase, the strongest implications are defensive. The stateless CEO model remains the safer Phase 1 default. Any Liaison or specialist memory should be treated as a separately governed surface, while operational visibility should remain subordinate to the coordination contract’s authorization boundaries. Metrics access, approval visibility, or isolated storage should not be mistaken for authority, confidentiality, or durable accountability.

The sources do not establish a complete governance system or demonstrate runtime behavioral safety. Their combined value is narrower and more durable: useful agent operations depend on controlling visibility, permission, and memory flow as distinct surfaces, with structural authorization and evidence outside the model.