Coding agents like Claude Code, Gemini CLI, Cline, and OpenClaw are no longer just for developers.
HR teams use them to automate onboarding workflows. Marketing uses them to generate and deploy content pipelines. Security auditors use them to scan codebases and configs. Finance uses them to build reporting automations. They’re all speaking to the same agentic runtime — but with very different intentions.
That’s a massive, underappreciated security gap.
Traditional access control was built for humans clicking through UIs. It doesn’t translate cleanly to natural language prompts issued to autonomous agents. “Clean up the old deployment” means something very different coming from a DevOps engineer versus an HR analyst — but the agent may execute the same destructive action either way.
We need a new layer: Intent-Based Access Control (IBAC).
The architecture looks like this:
Capture natural language — intercept the prompt before execution
Classify intent — use an LLM layer or simple NLP parser to extract the semantic intent category (read, write, delete, deploy, query, etc.) and the target resource domain (cloud infra, HR data, financial records)
Map to policy — bind that intent + identity context to a machine-readable access policy file (think IAM meets XACML, but for agent actions)
Enforce at runtime — block, escalate, or audit before the agent takes action
The result: an HR analyst’s prompt will never resolve to kubectl delete pod. Not because we filtered keywords, but because the intent was out of scope for that identity.
This is the missing control plane for enterprise agentic AI. RBAC gave us roles. ABAC gave us attributes. IBAC gives us meaning.
We’ve been building this at DistributedApps.ai for the past three months — and today we’re open sourcing it.
The GitHub repo has full setup instructions in the README. And if you want a deeper walkthrough, this is the tutorial to get you up and running fast.
GitHub Repository: https://github.com/kenhuangus/agentctlwith Claude Code, OpenClaw and Gemini CLI support)
Refer to my previous substack article on IBAC:
Why Unified Intent-Based Access Control?
Architecture: The Adapter Approach
Installation and Setup
Initializing agentctl
Runtime Discovery
Configuration Management
Registering Agents
Authoring Cedar Policies
Running with Claude Code
Running with OpenClaw
Running with Gemini CLI
Resource Override
Audit and Session Inspection
How Adapters Work: Claude Code Internals
Testing Your Setup
Recommended Workflow
End-to-End Usage Example
Modern AI agents operate across diverse, heterogeneous tool ecosystems: Claude Code provides Read/Write/Bash tools, OpenClaw offers code_read/code_write/shell operations, and Gemini CLI supplies file_read/code_search/file_write/shell commands. Each runtime uses different tool naming conventions, parameter structures, and execution models.
Without a unified governance layer, organizations face critical challenges:
Policy Fragmentation: Different policies needed for each agent runtime; impossible to enforce consistent security standardsAudit Blind Spots: Each runtime logs differently; linking operations across agents becomes a forensic nightmareCompliance Complexity: Meeting compliance requirements (HIPAA, SOC 2, PCI-DSS) requires normalizing divergent tool semanticsSecret Leakage: Without central control, agents may expose credentials through tool execution; context-based policies can’t be enforcedScale Governance: As your organization adds more coding agents, governance becomes exponentially harder without a unified control plane
agentctl introduces a unified IBAC layer that:
Normalizes Intent: Maps heterogeneous tool calls (Claude’s Read, OpenClaw’s code_read, Gemini’s file_read) to canonicalactions(read, write, execute)Enforces Policy Uniformly: Single Cedar policy set governs all agent runtimesProvides Transparency: --show-intent flag lets you inspect what action/resource an agent request translates to before enforcementEnables Granular Control: Policies can differ by:Agent identity (which agent is requesting)
Environment (dev/staging/prod)
Resource context (which file/directory is being accessed)
Time-based rules (office hours only, for example)
Creates Unified Audit Trail: All agent actions recorded in consistent JSONL format, linking tools, actions, and policy decisions
Imagine you’re integrating Claude Code for documentation cleanup and OpenClaw for infrastructure scripting:
Without agentctl:
Claude Code uses Read tool → you write Claude-specific policy for Read action
OpenClaw uses code_read tool → you write separate OpenClaw policy for code_read
Developer accidentally grants Read access thinking it’s safe; doesn’t realize code_read has same scope
Compliance audit finds inconsistent policies across agents; fails review
With agentctl:
Both Read and code_read normalize to canonical read action
Single Cedar policy rule: permit when principal.environment == “dev” and action == “read”
Both agents follow the same policy
Unified audit trail shows which tools each agent used, but all decisions came from the same rule
Compliance audit passes
agentctl uses a clean, extensible Adapter Pattern to achieve runtime normalization without coupling.
