feature / agent-governance#6423
Conversation
0xchikku
commented
May 22, 2026
- Add governance module with policy engine for tool execution control
- Implement audit logger to track tool proposals, policy decisions, and executions
- Add policy loader to parse and apply governance rules from JSON configuration
- Create governed tool wrapper for policy-gated tool execution
- Add human-in-the-loop (HITL) decision tracking in audit logs
- Include sample agent policies and audit logs for testing and documentation
- Update Agent node to integrate governance checks
- Add sqlite database to gitignore for local development
- Add governance module with policy engine for tool execution control - Implement audit logger to track tool proposals, policy decisions, and executions - Add policy loader to parse and apply governance rules from JSON configuration - Create governed tool wrapper for policy-gated tool execution - Add human-in-the-loop (HITL) decision tracking in audit logs - Include sample agent policies and audit logs for testing and documentation - Update Agent node to integrate governance checks - Add sqlite database to gitignore for local development
…tool actions - Add policy decision logging to audit.jsonl with deny/escalate/allow effects - Implement policy gate interface in packages/components/src/governance/gate.ts - Update Agent.ts to enforce policies before tool execution - Integrate policy checks into buildAgentflow utility for runtime validation - Add agent-policies.json configuration with channel posting rules - Update ChatMessage component to display policy decision context - Enhance Interface.ts with policy decision and audit event types - Update hackathon documentation with policy engine examples - Policies support deny (block action), escalate (require human review), and allow effects - Audit trail captures all policy decisions with rule IDs and human decisions for compliance
There was a problem hiding this comment.
Code Review
This pull request introduces a governance framework for Agent Flow v2, enabling policy-based control (allow, deny, escalate) over tool executions via a new policy engine and audit logging system. Feedback highlights high-severity path traversal vulnerabilities in the audit logging and policy loading utilities where user-configurable paths are not properly validated. Additionally, a suggestion was provided to relax a restrictive check in the policy engine's JSON flattening logic to better accommodate tool arguments containing metadata.
| } | ||
|
|
||
| export function appendAuditLog(auditPath: string, entry: Omit<AuditEntry, 'ts'>): void { | ||
| const resolved = path.isAbsolute(auditPath) ? auditPath : path.resolve(getRepoRoot(), auditPath) |
There was a problem hiding this comment.
The auditPath is resolved using path.isAbsolute and then used for file operations. Since this path can be configured via node inputs in the UI, it presents a potential path traversal vulnerability. An attacker could specify an absolute path or use .. segments to write logs to arbitrary locations on the server. You should validate that the resolved path is within an expected directory.
| } | ||
|
|
||
| export function loadPolicyFile(policyPath: string): PolicyFile { | ||
| const resolved = path.isAbsolute(policyPath) ? policyPath : path.resolve(getRepoRoot(), policyPath) |
There was a problem hiding this comment.
The policyPath is resolved using path.isAbsolute and then read directly from the filesystem. Since this path can be configured via the UI, it presents a potential path traversal vulnerability. An attacker could specify an absolute path (e.g., /etc/passwd) or use .. segments to read sensitive files. You should validate that the resolved path stays within an expected directory.
| */ | ||
| function flattenJsonInput(args: Record<string, unknown>): Record<string, unknown> { | ||
| const keys = Object.keys(args) | ||
| if (keys.length === 1 && keys[0] === 'input' && typeof args.input === 'string') { |
There was a problem hiding this comment.
The condition keys.length === 1 is too restrictive. LLMs or tool configurations might include additional metadata or optional fields in the args object alongside the primary input string. It is safer to check for the existence and type of args.input without strictly limiting the number of keys in the object.
| if (keys.length === 1 && keys[0] === 'input' && typeof args.input === 'string') { | |
| if (typeof args.input === 'string') { |
References
- A function's parameter type can intentionally include unused properties to allow callers to pass objects with a superset of fields without causing errors.
…metadata - Extract IAgentToolCallResult interface to standardize return type for handleToolCalls and handleResumedToolCalls methods - Add GovernanceMeta interface to encapsulate session, chat, and node identifiers for audit and governance tracking - Replace inline return type definitions with IAgentToolCallResult for improved type safety and maintainability - Update sourceDocuments and artifacts type annotations from Array<any> to ICommonObject[] for better type consistency - Add type annotation to governanceMeta variable using GovernanceMeta interface - Remove hardcoded default paths for policy and audit log files, allowing configuration-driven behavior - Import AIMessageChunk and IAgentToolCallResult where needed for type definitions
- Rename policyEngine.ts to policyEvaluator.ts for improved naming clarity - Update import in gate.ts to reference policyEvaluator module - Update export in index.ts to reference policyEvaluator module - Better aligns module name with its responsibility of evaluating policies
- Add audit trail entries for weather lookup and email sending workflows - Create demo.mjs showcasing agent policy enforcement with real-world scenarios - Update hackathon README with governance implementation details - Expand agent-policies.json with additional policy rules and examples - Enhance Agent.ts with improved policy evaluation integration - Refine governance types and gate logic for better policy decision handling - Demonstrates allow, escalate, and deny policy effects in action
- Remove getRepoRoot() helper from auditLogger and require absolute paths - Simplify auditLogger to use provided paths directly without resolution - Update Agent node default policy and audit log paths to absolute paths - Remove unused GovernanceEvent import from Agent.ts - Add new audit log entries demonstrating policy enforcement for weather queries - Streamline path handling to rely on caller-provided absolute paths
- Clear audit.jsonl of demo audit entries - Update Agent.ts to integrate governance metadata in tool execution - Refactor auditLogger.ts for improved audit event handling - Update Interface.ts with governance-related type definitions - Modify buildAgentflow.ts to pass governance context through agent flows - Update ChatMessage.jsx to display governance audit information in UI - Consolidate governance implementation across agent flow execution pipeline
…ructions - Split proceed decision into two paths: approve as-is (execute tool) and redirect (discard tool call, re-invoke LLM) - Replace arg modification model with instruction-based redirect: reviewers now provide plain-text instructions instead of modified args - Remove originalArgs and modifiedArgs from AuditEntry; simplify feedback field to capture reviewer instructions or notes - Update audit log display to show [redirect] indicator for proceed decisions with feedback - Add IHumanInput interface documenting the two proceed behaviors and instruction semantics - Update governance flowchart to show separate ProceedApprove and ProceedRedirect paths - Clarify audit lifecycle state diagram with conditional transitions based on instruction presence - Update demo scenario 5 to illustrate redirect flow: tool call discarded, instruction injected as user message, LLM re-invoked - Expand configuration field descriptions with clarity on required paths and governance enablement logic
- Update email domain regex pattern from @aivar.tech to @internal.tech - Update policy message to reflect new internal domain - Ensures agent policies reference correct internal email domain for permission validation
- Add audit log entries demonstrating policy enforcement workflows - Include examples of internal email allowance (allow-internal-email rule) - Include examples of external email escalation (escalate-external-email rule) - Document human-in-the-loop decision paths (proceed and reject scenarios) - Capture complete session lifecycle from start through policy evaluation to execution or escalation - Provide reference data for testing and validating governance audit logging
|
agent governance needs three layers:
layer 2 is what's typically missing. the governance layer says "this action is allowed" but there's no tamper-evident record of that decision. nobulex generates Ed25519 signed receipts for every governance decision. each receipt carries the policy_version that was in effect, so an auditor can verify not just what happened, but which rules were active at the time. github.com/arian-gogani/nobulex |