Skip to content

Add runtime policy, revocation, and audit correlation for generated tools#2547

Merged
senamakel merged 9 commits into
tinyhumansai:mainfrom
vaddisrinivas:codex/oh-2543-generated-tool-runtime-policy
May 25, 2026
Merged

Add runtime policy, revocation, and audit correlation for generated tools#2547
senamakel merged 9 commits into
tinyhumansai:mainfrom
vaddisrinivas:codex/oh-2543-generated-tool-runtime-policy

Conversation

@vaddisrinivas
Copy link
Copy Markdown
Contributor

@vaddisrinivas vaddisrinivas commented May 23, 2026

Summary

  • Add generated-tool runtime context to tool-policy requests.
  • Add a generic runtime policy that can allow, require approval, or deny by provider, capability, or risk.
  • Add generated-tool audit correlation fields for provider, capability, policy decision, and approval ID.

Problem

  • Generated capability tools need runtime enforcement after admission, including revocation and audit correlation, without hard-coding any one external provider or package format.
  • Existing policy decisions only modeled allow/deny, so callers could not express a policy-mandated approval state.

Solution

  • Extend ToolPolicyRequest with optional GeneratedToolRuntimeContext.
  • Add ToolPolicyDecision::RequireApproval and a shared blocking_reason helper so the existing session runner blocks non-allow decisions.
  • Add GeneratedToolRuntimePolicy and structured generated-tool audit helpers while preserving the default allow-all policy.

Submission Checklist

  • Tests added or updated (happy path + at least one failure / edge case) per Testing Strategy: disabled policy allow path, revoked provider, revoked capability, risk approval, and audit correlation fields.
  • Diff coverage ≥ 80% — local full coverage not run; focused Rust tests cover the changed modules and CI coverage gate will enforce final diff coverage.
  • Coverage matrix updated — N/A: generic policy/audit infrastructure, no existing feature row added/removed/renamed.
  • All affected feature IDs from the matrix are listed in the PR description under ## Related: N/A, no coverage-matrix feature ID applies.
  • No new external network dependencies introduced (mock backend used per Testing Strategy): no network dependency added.
  • Manual smoke checklist updated if this touches release-cut surfaces (docs/RELEASE-MANUAL-SMOKE.md): N/A, no release-cut UI/runtime smoke surface changed.
  • Linked issue closed via Closes #NNN in the ## Related section.

Impact

  • Runtime/platform impact: policy-aware callers can pass generated-tool context and enforce revocations before execution.
  • Security impact: enables runtime provider/capability/risk policy gates and audit correlation for generated capability tools.
  • Compatibility: default policy and requests without generated-tool context retain existing behavior.

Related


AI Authored PR Metadata (required for Codex/Linear PRs)

Linear Issue

Commit & Branch

  • Branch: codex/oh-2543-generated-tool-runtime-policy
  • Commit SHA: 7445c7dfc996f1503508cd628f44ed670400de87

Validation Run

  • pnpm --filter openhuman-app format:check: N/A, Rust-only backend policy/audit change.
  • pnpm typecheck: N/A, Rust-only backend policy/audit change.
  • Focused tests: cargo test --manifest-path Cargo.toml generated_runtime_policy --lib; cargo test --manifest-path Cargo.toml audit_log_generated_tool --lib; cargo test --manifest-path Cargo.toml threads_generated_tool_context --lib
  • Rust fmt/check (if changed): cargo fmt --manifest-path Cargo.toml --all --check; git diff --check
  • Tauri fmt/check (if changed): N/A, no Tauri code changed.
  • PR checklist: node scripts/check-pr-checklist.mjs /tmp/openhuman-pr-body-2543.md

Validation Blocked

  • command: N/A
  • error: N/A
  • impact: N/A

Behavior Changes

  • Intended behavior change: callers can model generated-tool runtime policy outcomes including approval-required decisions.
  • User-visible effect: None by default; allow-all policy remains unchanged unless callers install the stricter policy and context.

Parity Contract

  • Legacy behavior preserved: yes, requests without generated-tool context and the default allow-all policy behave as before.
  • Guard/fallback/dispatch parity checks: non-allow decisions are blocked before tool execution, matching existing denial placement.

Duplicate / Superseded PR Handling

  • Duplicate PR(s): None found for vaddisrinivas:codex/oh-2543-generated-tool-runtime-policy.
  • Canonical PR: this PR.
  • Resolution (closed/superseded/updated): N/A.

Summary by CodeRabbit

  • New Features

    • New generated-tool runtime policy with revoked provider/capability controls, per-provider/capability and risk-based actions.
    • Tool executions can now produce optional runtime metadata that influences policy decisions.
    • Introduced a "require approval" outcome (in addition to allow/deny) and clearer human-readable decision labels.
    • Audit entries now include provider, capability, policy decision, risk and approval identifiers.
  • Tests

    • Added coverage for allow/deny/require-approval behaviors and audit serialization.

Review Change Stack

@vaddisrinivas vaddisrinivas requested a review from a team May 23, 2026 15:46
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 23, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8a78ebf9-35b7-4fb4-85ea-8054bd73a1f2

📥 Commits

Reviewing files that changed from the base of the PR and between 7445c7d and c9bb42f.

📒 Files selected for processing (1)
  • app/src/pages/onboarding/steps/__tests__/WelcomeStep.test.tsx
💤 Files with no reviewable changes (1)
  • app/src/pages/onboarding/steps/tests/WelcomeStep.test.tsx

📝 Walkthrough

Walkthrough

Adds generated-tool runtime context to policy requests, a RequireApproval decision and blocking_reason(), GeneratedToolRuntimePolicy implementation and tests, a Tool hook to supply context, executor threading and denial handling, and audit correlation for generated-tool events.

Changes

Generated Tool Policy and Audit

Layer / File(s) Summary
Policy types and generated-tool enforcement logic
src/openhuman/agent/tool_policy.rs
ToolPolicyRequest carries optional GeneratedToolRuntimeContext. ToolPolicyDecision gains RequireApproval { reason } and blocking_reason(). GeneratedToolRuntimePolicy and config implement revocation lists and provider/capability/risk action mappings with precedence; tests validate allow/deny/require-approval cases.
Policy decision extraction in tool execution
src/openhuman/agent/harness/session/turn.rs
Agent::execute_tool_call builds a mutable ToolPolicyRequest, threads tool.generated_runtime_context(...) into it before tool_policy.check, and uses policy_decision.blocking_reason() to handle deny/require-approval outcomes with unified logging and denial messaging.
Tool hook and harness tests
src/openhuman/tools/traits.rs, src/openhuman/agent/harness/session/turn_tests.rs
Adds Tool::generated_runtime_context(&self, args) -> Option<GeneratedToolRuntimeContext> and tests a GeneratedContextTool + RequireGeneratedContextPolicy asserting generated context is passed into the policy and that require-approval/deny prevents tool invocation and is recorded.
Audit metadata and generated-tool event logging
src/openhuman/security/audit.rs
Action gains optional provider_id, capability_id, policy_decision, approval_id. Adds GeneratedToolExecutionLog, AuditEvent::with_generated_tool_action, AuditLogger::log_generated_tool_event, and a test covering serialization of correlation fields.
Onboarding test whitespace
app/src/pages/onboarding/steps/__tests__/WelcomeStep.test.tsx
Adds a blank line in the test (no behavioral change).

Sequence Diagram

sequenceDiagram
    participant Agent as Agent::execute_tool_call
    participant Policy as GeneratedToolRuntimePolicy::check
    participant Decision as ToolPolicyDecision
    participant Audit as AuditLogger::log_generated_tool_event
    Agent->>Policy: check(request + generated_tool context)
    Policy->>Decision: Allow / RequireApproval / Deny (with reason)
    Decision->>Agent: decision (optional blocking reason)
    alt blocked or requires approval
        Agent->>Audit: log_generated_tool_event(provider_id, capability_id, policy_decision, approval_id)
    else allowed
        Agent->>Agent: proceed with tool execution
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Suggested reviewers

  • graycyrus
  • senamakel

Poem

🐰 I thread the tool's small whisper through the rule,

provider, capability, and reason as a spool.
If approval's needed I hop to the audit with care,
else I let the allowed tools bound through the air.
A rabbit's log: every hop noted fair.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main changes: adding runtime policy, revocation support, and audit correlation specifically for generated tools.
Linked Issues check ✅ Passed All acceptance criteria from #2543 are met: config-backed runtime policy by provider/capability/risk [#2543], allow/deny/approval-required outcomes [#2543], revocation enforcement [#2543], structured denial reasons [#2543], audit correlation fields [#2543], backward compatibility [#2543], and focused tests [#2543].
Out of Scope Changes check ✅ Passed All changes are directly related to PR objectives; the minor formatting fix in WelcomeStep.test.tsx is incidental maintenance (not out-of-scope).
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot added feature Net-new user-facing capability or product behavior. rust-core Core Rust runtime in src/: CLI, core_server, shared infrastructure. agent Built-in agents, prompts, orchestration, and agent runtime in src/openhuman/agent/. labels May 23, 2026
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
src/openhuman/agent/tool_policy.rs (1)

236-310: ⚡ Quick win

Add branch-level debug tracing for runtime policy decisions.

At Lines 236-310, generated-tool policy evaluation has multiple enforcement branches (revoked provider/capability, provider/capability/risk mappings, default allow) but emits no local debug/trace diagnostics, which makes runtime policy outcomes hard to audit during incidents.

♻️ Suggested patch
 impl GeneratedToolRuntimePolicy {
@@
     fn action_for(
         &self,
         tool_name: &str,
         context: &GeneratedToolRuntimeContext,
     ) -> (RuntimeToolPolicyAction, String) {
@@
-        if let Some(action) = self.config.risk_actions.get(&context.risk) {
+        if let Some(action) = self.config.risk_actions.get(&context.risk) {
             return (
                 *action,
                 format!("risk `{:?}` matched runtime policy", context.risk),
             );
         }
         (
             RuntimeToolPolicyAction::Allow,
             format!("tool `{tool_name}` allowed"),
         )
     }
 }
@@
     async fn check(&self, request: &ToolPolicyRequest) -> ToolPolicyDecision {
         if !self.config.enabled {
+            tracing::trace!(
+                policy = self.name(),
+                tool = request.tool_name.as_str(),
+                "[rpc] generated tool runtime policy disabled; allowing"
+            );
             return ToolPolicyDecision::Allow;
         }
         let Some(context) = request.generated_tool.as_ref() else {
+            tracing::trace!(
+                policy = self.name(),
+                tool = request.tool_name.as_str(),
+                "[rpc] generated tool context missing; allowing"
+            );
             return ToolPolicyDecision::Allow;
         };
         let (action, reason) = self.action_for(&request.tool_name, context);
+        tracing::debug!(
+            policy = self.name(),
+            tool = request.tool_name.as_str(),
+            provider_id = context.provider_id.as_str(),
+            capability_id = context.capability_id.as_str(),
+            risk = ?context.risk,
+            action = ?action,
+            reason = reason.as_str(),
+            "[rpc] generated tool runtime policy decision"
+        );
         match action {
             RuntimeToolPolicyAction::Allow => ToolPolicyDecision::Allow,
             RuntimeToolPolicyAction::RequireApproval => {
                 ToolPolicyDecision::require_approval(reason)
             }
             RuntimeToolPolicyAction::Deny => ToolPolicyDecision::deny(reason),
         }
     }
 }

As per coding guidelines: "Use log / tracing at debug or trace level on ... state transitions, and any branch that is hard to infer from tests alone."

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/agent/tool_policy.rs` around lines 236 - 310, The
action_for/check flow in GeneratedToolRuntimePolicy lacks branch-level debug
tracing; add debug or trace logs inside GeneratedToolRuntimePolicy::action_for
for each branch (revoked provider, revoked capability, capability_actions hit,
provider_actions hit, risk_actions hit, and default allow) emitting the chosen
RuntimeToolPolicyAction, the formatted reason, tool_name, context.provider_id,
context.capability_id, and context.risk as appropriate, and also log the final
decision in GeneratedToolRuntimePolicy::check right before returning the
ToolPolicyDecision (use ToolPolicyDecision::require_approval / deny / Allow
paths); reference the action_for function, the RuntimeToolPolicyAction enum, and
the check method to locate insertion points.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/openhuman/agent/harness/session/turn.rs`:
- Around line 1202-1205: The policy check is using ToolPolicyRequest::new which
leaves generated_tool as None so generated-tool runtime policy rules never run;
before calling self.tool_policy.check(&policy_request).await, populate the
request's generated_tool context (e.g., via the request builder/constructor that
accepts generated tool metadata or by setting the generated_tool field on the
ToolPolicyRequest you created) so the generated-tool runtime policy (revoked
provider/capability/risk action mappings) is available to the check; update the
code path around ToolPolicyRequest::new and the call site of
self.tool_policy.check to pass the generated tool context into the request.

---

Nitpick comments:
In `@src/openhuman/agent/tool_policy.rs`:
- Around line 236-310: The action_for/check flow in GeneratedToolRuntimePolicy
lacks branch-level debug tracing; add debug or trace logs inside
GeneratedToolRuntimePolicy::action_for for each branch (revoked provider,
revoked capability, capability_actions hit, provider_actions hit, risk_actions
hit, and default allow) emitting the chosen RuntimeToolPolicyAction, the
formatted reason, tool_name, context.provider_id, context.capability_id, and
context.risk as appropriate, and also log the final decision in
GeneratedToolRuntimePolicy::check right before returning the ToolPolicyDecision
(use ToolPolicyDecision::require_approval / deny / Allow paths); reference the
action_for function, the RuntimeToolPolicyAction enum, and the check method to
locate insertion points.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e9224089-8318-4a32-ba09-0fbac4e981b7

📥 Commits

Reviewing files that changed from the base of the PR and between f8c9698 and 4b144df.

📒 Files selected for processing (3)
  • src/openhuman/agent/harness/session/turn.rs
  • src/openhuman/agent/tool_policy.rs
  • src/openhuman/security/audit.rs

Comment thread src/openhuman/agent/harness/session/turn.rs Outdated
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 24, 2026
@YOMXXX
Copy link
Copy Markdown
Contributor

YOMXXX commented May 24, 2026

Security/review note: the new RequireApproval policy state is currently treated as a blocking denial in Agent::execute_tool_call via blocking_reason(); the new test also asserts the tool is not executed and the result is unsuccessful when approval is required. That is a safe fail-closed behavior, but it is not yet an approval-request flow.\n\nFor reviewer clarity, I would either (a) document/rename this v1 behavior as "block pending an approval integration" and keep it as a safe primitive, or (b) wire it into the existing approval request/decision path before claiming the acceptance criterion "approval-required outcome". The current shape is good from a safety perspective, but product semantics could surprise future callers that expect a user approval prompt instead of an immediate failed tool result.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (3)
src/openhuman/agent/tool_policy.rs (1)

455-507: ⚡ Quick win

Add a regression test for the enabled + missing generated context allow path.

That branch is the backward-compatibility escape hatch, but the new tests only cover enabled=false and enabled=true with generated context. A future change here could start blocking built-in tools without a test catching it.

Proposed test shape
+    #[tokio::test]
+    async fn generated_runtime_policy_allows_when_context_missing() {
+        let policy = GeneratedToolRuntimePolicy::new(GeneratedToolRuntimePolicyConfig {
+            enabled: true,
+            ..Default::default()
+        });
+
+        let request = ToolPolicyRequest::new(
+            "echo",
+            serde_json::json!({ "value": 1 }),
+            ToolCallContext::session("session", "chat", "orchestrator", "call-1", 1),
+        );
+
+        assert_eq!(policy.check(&request).await, ToolPolicyDecision::Allow);
+    }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/agent/tool_policy.rs` around lines 455 - 507, Add a regression
test to ensure the Enabled=true but missing generated context path returns
Allow: create a new #[tokio::test] (e.g.,
generated_runtime_policy_allows_when_enabled_but_missing_context) that
constructs GeneratedToolRuntimePolicy::new(GeneratedToolRuntimePolicyConfig {
enabled: true, ..Default::default() }), call
policy.check(&generated_request_missing_context()).await (or reuse
generated_request() but remove/omit the generated context fields), and assert
the result equals ToolPolicyDecision::Allow; reference
GeneratedToolRuntimePolicy, GeneratedToolRuntimePolicyConfig, policy.check, and
generated_request to locate where to add the test so built-in tools remain
allowed when generated context is absent.
src/openhuman/agent/harness/session/turn.rs (1)

1204-1230: ⚡ Quick win

Extract this policy gate into a small helper.

execute_tool_call is already carrying a lot of hot-path responsibility, and this new generated-context enrichment + block-message formatting adds another policy-specific branch inline. Pulling it into a helper would make future policy changes easier and stop growing an already oversized module.

As per coding guidelines **/*.{ts,tsx,rs}: File size should not exceed approximately 500 lines. When a module grows beyond this threshold, split it into smaller, more focused modules with clear responsibilities.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/agent/harness/session/turn.rs` around lines 1204 - 1230, The
policy-check block inside execute_tool_call (creating ToolPolicyRequest,
enriching it with tool.generated_runtime_context(&call.arguments), calling
self.tool_policy.check(&policy_request).await, inspecting
policy_decision.blocking_reason(), and formatting the blocked message) should be
extracted into a small helper function (e.g. compute_tool_policy_outcome or
check_tool_policy) that takes the tool name, call.arguments, and context and
returns a (message, allowed: bool) or a custom enum; move the ToolPolicyRequest
creation and the with_generated_tool_context call, the self.tool_policy.check
invocation, and the ToolPolicyDecision match/formatting into that helper, and
replace the inline block in execute_tool_call with a single call to the new
helper so future policy changes and generated_runtime_context enrichment live in
their own unit.
src/openhuman/agent/harness/session/turn_tests.rs (1)

655-695: 🏗️ Heavy lift

Move the generated-tool policy cases into their own test module.

This file is already very large and now mixes turn lifecycle, transcript, memory, prompt, and generated-tool policy coverage. Splitting these new cases into a dedicated sibling test module would make failures easier to localize and keep this suite navigable.

As per coding guidelines **/*.{ts,tsx,rs}: File size should not exceed approximately 500 lines. When a module grows beyond this threshold, split it into smaller, more focused modules with clear responsibilities.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/agent/harness/session/turn_tests.rs` around lines 655 - 695,
Split the generated-tool policy tests (e.g., the test function
execute_tool_call_threads_generated_tool_context_into_policy and any related
helpers/types like GeneratedContextTool, RequireGeneratedContextPolicy,
ParsedToolCall) out of the large turn_tests.rs into a new sibling test module
file (e.g., generated_tool_policy_tests.rs) and update module imports; move the
test functions and any small helper structs/fixtures they rely on, add the
necessary use/imports (tokio::test, tempfile, Arc, AtomicUsize, Ordering,
Agent::builder, XmlToolDispatcher, Memory creation helpers) at the top of the
new file, keep the #[tokio::test] attributes and assertions unchanged, and
ensure the new file is included in the test build (via mod declaration or Cargo
test discovery) so the tests compile and run as before.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/openhuman/agent/harness/session/turn_tests.rs`:
- Around line 655-695: Split the generated-tool policy tests (e.g., the test
function execute_tool_call_threads_generated_tool_context_into_policy and any
related helpers/types like GeneratedContextTool, RequireGeneratedContextPolicy,
ParsedToolCall) out of the large turn_tests.rs into a new sibling test module
file (e.g., generated_tool_policy_tests.rs) and update module imports; move the
test functions and any small helper structs/fixtures they rely on, add the
necessary use/imports (tokio::test, tempfile, Arc, AtomicUsize, Ordering,
Agent::builder, XmlToolDispatcher, Memory creation helpers) at the top of the
new file, keep the #[tokio::test] attributes and assertions unchanged, and
ensure the new file is included in the test build (via mod declaration or Cargo
test discovery) so the tests compile and run as before.

In `@src/openhuman/agent/harness/session/turn.rs`:
- Around line 1204-1230: The policy-check block inside execute_tool_call
(creating ToolPolicyRequest, enriching it with
tool.generated_runtime_context(&call.arguments), calling
self.tool_policy.check(&policy_request).await, inspecting
policy_decision.blocking_reason(), and formatting the blocked message) should be
extracted into a small helper function (e.g. compute_tool_policy_outcome or
check_tool_policy) that takes the tool name, call.arguments, and context and
returns a (message, allowed: bool) or a custom enum; move the ToolPolicyRequest
creation and the with_generated_tool_context call, the self.tool_policy.check
invocation, and the ToolPolicyDecision match/formatting into that helper, and
replace the inline block in execute_tool_call with a single call to the new
helper so future policy changes and generated_runtime_context enrichment live in
their own unit.

In `@src/openhuman/agent/tool_policy.rs`:
- Around line 455-507: Add a regression test to ensure the Enabled=true but
missing generated context path returns Allow: create a new #[tokio::test] (e.g.,
generated_runtime_policy_allows_when_enabled_but_missing_context) that
constructs GeneratedToolRuntimePolicy::new(GeneratedToolRuntimePolicyConfig {
enabled: true, ..Default::default() }), call
policy.check(&generated_request_missing_context()).await (or reuse
generated_request() but remove/omit the generated context fields), and assert
the result equals ToolPolicyDecision::Allow; reference
GeneratedToolRuntimePolicy, GeneratedToolRuntimePolicyConfig, policy.check, and
generated_request to locate where to add the test so built-in tools remain
allowed when generated context is absent.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e3d42823-8558-4ccc-97a2-47b2157b3ff9

📥 Commits

Reviewing files that changed from the base of the PR and between f810dfa and 7445c7d.

📒 Files selected for processing (3)
  • src/openhuman/agent/harness/session/turn.rs
  • src/openhuman/agent/harness/session/turn_tests.rs
  • src/openhuman/agent/tool_policy.rs

coderabbitai[bot]
coderabbitai Bot previously approved these changes May 24, 2026
@senamakel senamakel self-assigned this May 25, 2026
Fix compile error in turn_tests where `create_memory` was imported from
`crate::openhuman::memory` instead of `crate::openhuman::memory_store`.
Add regression test for the enabled-but-missing-generated-context allow
path (addresses @coderabbitai nitpick on tool_policy.rs).
@senamakel
Copy link
Copy Markdown
Member

@YOMXXX Good observation re: RequireApproval semantics. The current code already documents this on the RequireApproval variant itself (lines 141-145 of tool_policy.rs):

Session execution currently treats this as fail-closed through blocking_reason(). Callers that can prompt for approval may branch on this variant and retry after approval is granted.

This is intentionally a safe v1 primitive — fail-closed by default, with the variant preserved so a future approval-prompt integration can branch on RequireApproval vs Deny without changing the enum. Wiring it into a real approval flow is out of scope for this PR but the type system is ready for it.

@senamakel senamakel merged commit ae699a0 into tinyhumansai:main May 25, 2026
27 of 29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agent Built-in agents, prompts, orchestration, and agent runtime in src/openhuman/agent/. feature Net-new user-facing capability or product behavior. rust-core Core Rust runtime in src/: CLI, core_server, shared infrastructure.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add runtime policy, revocation, and audit correlation for generated tools

3 participants