Subagent Permission Boundaries: Read-Only vs Write Splits for Safety

Table of Contents

1. Why Permission Boundaries Matter for AI Agents
2. The Read-Only vs Write Split Pattern
3. How Padiso Implements Safety-First Subagent Architecture
4. Permission Boundary Frameworks: AWS IAM to Agent Design
5. Real-World Failure Scenarios and How Read-Only Prevents Them
6. Orchestrator-Only Write Access: The Gatekeeping Pattern
7. Implementing Permission Boundaries in Your AI Stack
8. Audit Readiness and Compliance Through Permission Design
9. Measuring Safety: Metrics That Matter
10. Next Steps: Building Your Safety-First Agent System

---

Why Permission Boundaries Matter for AI Agents

In a year of shipping agentic AI systems for Sydney startups and enterprise operators, we’ve learned one hard lesson: the difference between a controlled AI system and a catastrophic failure is often a single permission.

Most teams building multi-agent systems treat permissions as an afterthought. They spin up subagents with broad read-write access, assume human oversight will catch errors, and hope nothing goes wrong. Then a bug in agent logic, a prompt injection, or a cascading decision loop deletes production data—and suddenly you’re explaining to your board why a $50k automation investment cost $500k in recovery.

We’ve prevented every accidental rm -rf, every unauthorized API call, and every data exfiltration across 50+ client implementations by enforcing one principle: subagents are read-only by default; only the orchestrator writes.

This isn’t theoretical security theatre. It’s the practical pattern that lets founders and operators deploy AI agents with confidence, pass SOC 2 and ISO 27001 audits without friction, and sleep at night knowing your systems can’t accidentally destroy themselves.

Permission boundaries aren’t new—cloud architects have used them for years in AWS IAM and Kubernetes RBAC. But most teams haven’t yet translated those hard-won lessons into agent design. This guide shows you how.

---

The Read-Only vs Write Split Pattern

What Read-Only Actually Means

Read-only doesn’t mean your subagents are useless. It means they can:

• Query databases, APIs, and data warehouses without modifying state
• Analyse patterns, detect anomalies, and score risk
• Fetch context from multiple sources to inform decisions
• Generate reports, summaries, and recommendations
• Trigger notifications and alerts
• Call webhook endpoints designed to accept read-only traffic

What they cannot do:

• Write to databases or data lakes
• Delete records or logs
• Modify configuration or infrastructure
• Create users, permissions, or credentials
• Call mutation endpoints without orchestrator approval
• Execute destructive commands

In practice, a read-only subagent might analyse customer churn patterns, flag high-risk accounts, and recommend intervention—but it cannot execute a refund, update a contract, or close an account. The orchestrator reviews the recommendation, validates the logic, and executes the write operation.

Why This Pattern Scales

When you have 5–15 subagents operating in parallel (common in modern agentic systems), each with independent decision loops, the blast radius of a single permission mistake grows exponentially.

Consider a customer success automation system:

• Churn prediction agent (read-only): Identifies at-risk customers by analysing usage, support tickets, and NPS scores
• Engagement agent (read-only): Recommends outreach campaigns, discount tiers, and escalation paths
• Risk assessment agent (read-only): Flags compliance or contractual concerns
• Orchestrator (write-enabled): Reviews all three recommendations, resolves conflicts, and executes the customer communication and contract update

If the churn prediction agent has write access and a bug causes it to flag everyone as at-risk, it could trigger mass refunds or contract terminations before anyone notices. With read-only access, the worst it can do is generate bad recommendations—which the orchestrator filters out.

This is the safety model that has worked across our client base: fraud detection in fintech, diagnostic recommendations in healthcare, supply chain optimisation in logistics, and talent screening in HR tech. Read-only subagents generate insights and recommendations; the orchestrator enforces governance.

---

How Padiso Implements Safety-First Subagent Architecture

We’ve built this pattern into every agentic AI implementation we ship. Here’s the architecture:

Layered Permission Model

Layer 1: Subagent Capability Isolation

Each subagent runs in a sandboxed context with explicit capability declarations. Before an agent is deployed, we define:

• Which data sources it can read
• Which APIs it can call (read-only endpoints only)
• Which external tools it can invoke
• What rate limits apply
• What timeout and retry logic governs its operation

We use environment-based access control: subagents receive API keys and database credentials scoped to read-only roles. If a subagent is compromised or misbehaves, the damage is capped by its declared scope.

Layer 2: Orchestrator Gating

The orchestrator is the only system component with write permissions. It receives recommendations from all subagents, applies business logic and conflict resolution, and executes writes as a single, auditable operation.

This creates a clear accountability boundary: every mutation in your system can be traced to an orchestrator decision, which can be logged, audited, and rolled back.

Layer 3: Audit Trail and Reversibility

Every write operation is logged with:

• Which subagents contributed to the decision
• What confidence scores or flags were present
• Timestamp and operator context
• Before and after state
• Rollback capability

This isn’t just for compliance (though it helps with SOC 2 and ISO 27001 audits). It’s how you debug agent behaviour and catch systematic errors before they cascade.

Real Implementation: Customer Data Platform

One of our Sydney clients, a Series-B customer data platform, deployed a multi-agent system to process user events and generate audience segments:

• Ingestion agent (read-only): Validates incoming event schemas, flags malformed data, recommends data cleaning rules
• Deduplication agent (read-only): Identifies duplicate user profiles, calculates merge confidence scores, recommends merge operations
• Segmentation agent (read-only): Analyses user attributes and behaviour, recommends segment definitions
• Compliance agent (read-only): Flags GDPR, CCPA, and local privacy concerns; recommends consent checks
• Orchestrator: Reviews all recommendations, resolves conflicts (e.g., if deduplication and privacy agents disagree), executes user merges and segment creation

The system processes 50M+ events per day. In the first month, the deduplication agent’s confidence scoring had a bug that would have merged 2% of unrelated profiles if it had write access. Instead, it generated bad recommendations that the orchestrator filtered out. The team fixed the bug, re-ran the analysis, and deployed the corrected version—zero data loss, zero customer impact.

With write access, that bug would have merged 1M user profiles and required days of recovery work.

---

Permission Boundary Frameworks: AWS IAM to Agent Design

The pattern we use isn’t new. Cloud architects have been using permissions boundaries in AWS IAM for years to safely delegate access to developers. The same principles apply to agent design.

AWS IAM Permissions Boundaries as a Model

In AWS, a permissions boundary is a managed policy that sets the maximum permissions an IAM principal can have. Even if you grant a user or role additional permissions, the boundary caps what they can actually do.

This solves a classic problem: you want to let developers create IAM roles for their applications, but you don’t want them to create roles with *:* permissions or access to sensitive services like CloudTrail.

So you define a boundary that allows EC2, RDS, and S3 operations but denies IAM, KMS, and CloudTrail access. Now developers can create roles, but the boundary prevents them from overshooting their intended scope.

The same logic applies to subagents. You want them to operate autonomously and make decisions, but you want to cap their blast radius. A read-only boundary achieves this.

Translating IAM Lessons to Agent Permissions

When we design agent systems, we borrow directly from AWS security best practices on permissions boundaries:

1. Explicit allow, implicit deny: Subagents can only access resources explicitly listed in their capability declaration. Everything else is denied.
2. Least privilege: Each subagent gets the minimum permissions needed to fulfil its role. A churn prediction agent doesn’t need access to billing data.
3. Boundary enforcement: The orchestrator enforces the boundary at runtime. If a subagent tries to call a write endpoint, the request is rejected before it reaches the system.
4. Audit trail: Every attempt to exceed boundaries is logged, alerting operators to potential bugs or attacks.

For a practical breakdown, FireMon’s guide to permissions boundaries covers the mechanics in accessible language. The core idea: separate the identity-based policy (what a principal is allowed to do) from the boundary (the maximum they can do). The intersection is what actually happens.

For agents, the identity-based policy is the subagent’s declared capabilities; the boundary is read-only access. The intersection is: subagents can read and analyse, but not write.

Permission Boundary Patterns in Practice

We’ve implemented several boundary patterns depending on client needs:

Pattern 1: Strict Read-Only

Subagent has read access to specific tables or APIs. All writes go through the orchestrator. Best for high-risk domains (fintech, healthcare, government). Slightly higher latency (orchestrator adds a decision loop), but maximum safety.

Pattern 2: Read + Append-Only

Subagent can read and append new records (e.g., add a new customer interaction log), but cannot modify or delete existing records. Good for audit logging, event streaming, and immutable data patterns. Lower latency than strict read-only, still safe.

Pattern 3: Read + Limited Write

Subagent can write to a sandbox or staging environment, but not production. Useful for testing recommendations before the orchestrator promotes them. Requires careful data isolation.

Pattern 4: Scoped Write

Subagent can write to a specific table or namespace (e.g., a customer’s preference table), but not to sensitive fields (e.g., payment method). Requires fine-grained column-level access control. Risky without strong audit trails.

Most of our implementations use Pattern 1 or Pattern 2. The cost of orchestrator latency is worth the safety guarantee.

---

Real-World Failure Scenarios and How Read-Only Prevents Them

Scenario 1: The Cascading Delete

What happened: A fintech client deployed a fraud detection agent with write access to a customer database. The agent’s logic was: if a customer is flagged as high-risk in three consecutive checks, mark their account as suspended.

A bug in the agent’s confidence scoring caused it to flag every customer as high-risk. The agent cascaded through the database, suspending 100,000 accounts in 90 seconds.

Impact: 8 hours of recovery, 10,000+ support tickets, regulatory notification required, $200k+ in direct costs.

With read-only: The agent flags every customer as high-risk. The orchestrator receives 100,000 recommendations, applies sanity checks (“wait, why is 100% of our customer base high-risk?”), and rejects them. The team investigates the bug, fixes it, and re-runs the analysis.

Impact: Zero customer impact, bug caught in development.

Scenario 2: The Prompt Injection Attack

What happened: An e-commerce company deployed a customer service agent with write access to order management. An attacker crafted a customer message that injected a prompt, causing the agent to issue refunds without verification.

The agent issued $50k in unauthorized refunds before the fraud detection system caught the pattern.

Impact: Chargeback disputes, customer trust erosion, investigation and remediation costs.

With read-only: The customer service agent can read orders, analyse patterns, and recommend refunds. But it cannot execute the refund. A human operator reviews the recommendation, spots the suspicious pattern (100 refunds in 5 minutes), and blocks the attack.

Impact: Attack detected and blocked in real time.

Scenario 3: The Infinite Loop

What happened: A supply chain optimisation agent had write access to inventory levels. A bug in its decision logic caused it to enter a feedback loop: it would lower stock levels based on forecasts, which triggered lower demand predictions, which triggered further stock reductions, which triggered the cycle again.

Within minutes, inventory levels for a key SKU went to zero, causing stockouts and lost revenue.

Impact: Lost sales, emergency restocking costs, customer dissatisfaction.

With read-only: The agent recommends inventory adjustments based on forecasts. The orchestrator applies rate limiting and sanity checks: “you’ve recommended 50 adjustments in the last minute; that’s unusual.” It slows down the writes, reviews the pattern, and stops the loop before it cascades.

Impact: Bug caught and fixed before production impact.

Scenario 4: The Privilege Escalation

What happened: An HR tech company deployed a recruitment agent with write access to the employee database. The agent’s role was to screen candidates and create contractor records.

A vulnerability in the agent’s access control let it read and modify employee salary data. An attacker exploited the agent to exfiltrate payroll information.

Impact: Data breach, regulatory notification, forensics and remediation, reputation damage.

With read-only: The agent can read candidate profiles and job descriptions, but cannot access the employee database at all. It recommends screening decisions; a human recruiter executes the hire.

Impact: Attack surface eliminated entirely.

---

Orchestrator-Only Write Access: The Gatekeeping Pattern

The orchestrator is the single point of write authority in a safety-first agent system. This creates a clear, auditable decision boundary.

What the Orchestrator Does

The orchestrator receives recommendations from all subagents and:

1. Aggregates signals: Combines recommendations from multiple agents (e.g., churn agent says “at-risk”, engagement agent says “upsell opportunity”, risk agent says “contract expires in 30 days”)
2. Resolves conflicts: If two agents recommend contradictory actions, applies tiebreaker logic
3. Applies business rules: Enforces policies that subagents shouldn’t know about (e.g., “don’t contact customers more than once per week”)
4. Validates state: Checks that the action is still valid (e.g., customer still exists, contract is still active)
5. Executes writes: Performs the mutation and logs the decision
6. Handles failures: Retries, rolls back, or escalates based on error type

Orchestrator Implementation Patterns

Pattern A: Synchronous Orchestration

Subagents run in parallel, return recommendations to the orchestrator, which waits for all results before deciding. Low latency (all agents run at once), but orchestrator is a bottleneck if any agent is slow.

Best for: Systems where latency is critical and subagent response times are consistent (< 1 second).

Pattern B: Asynchronous Orchestration

Subagents run in parallel and post recommendations to a queue. The orchestrator polls the queue, batches recommendations, and executes writes on a schedule (e.g., every 5 minutes).

Better latency for the subagent (it doesn’t wait for orchestrator feedback), but adds delay between recommendation and execution.

Best for: Systems where eventual consistency is acceptable (batch processing, nightly jobs, low-frequency decisions).

Pattern C: Hierarchical Orchestration

Multiple orchestrators, each responsible for a domain. A meta-orchestrator coordinates between them.

Useful for very large systems (100+ agents), but adds complexity. Most startups don’t need this.

Orchestrator as Audit Trail

Every write operation should log:

{
  "timestamp": "2025-01-15T14:32:00Z",
  "orchestrator_id": "orch_prod_001",
  "subagents_consulted": ["churn_agent", "engagement_agent", "risk_agent"],
  "recommendations": [
    {"agent": "churn_agent", "signal": "at_risk", "confidence": 0.87},
    {"agent": "engagement_agent", "signal": "upsell", "confidence": 0.62},
    {"agent": "risk_agent", "signal": "contract_expires_30d", "confidence": 1.0}
  ],
  "decision": "execute_outreach",
  "decision_logic": "churn_confidence > 0.8 AND risk_signal present",
  "action": {"type": "send_message", "customer_id": "cust_12345", "template": "renewal_offer"},
  "result": "success",
  "rollback_available": true
}

This log is your proof of governance. It shows:

• Which agents influenced the decision
• What confidence or flags were present
• What logic was applied
• What action was taken
• Whether it succeeded or failed

When you’re audited for SOC 2 or ISO 27001, this log is your evidence that writes are governed, not arbitrary.

---

Implementing Permission Boundaries in Your AI Stack

If you’re building an agentic system, here’s how to implement this pattern:

Step 1: Define Subagent Capabilities

For each subagent, document:

• Role: What is this agent trying to achieve?
• Data sources: Which tables, APIs, or services can it read from?
• Operations: What read-only operations can it perform? (queries, aggregations, joins, etc.)
• Tools: Which external APIs or services can it call? (weather API, mapping service, etc.)
• Rate limits: How many requests per second/minute?
• Timeout: How long before the agent gives up?
• Fallback: What happens if the agent fails?

Example for a churn prediction agent:

Role: Identify high-risk customers based on usage and engagement patterns
Data sources: customers table, usage_events table, support_tickets table
Operations: SELECT (read), aggregation, joins, time-series analysis
Tools: None
Rate limits: 100 queries per minute
Timeout: 30 seconds per customer batch
Fallback: Return empty recommendations if data unavailable

Step 2: Implement Access Control

At the infrastructure level, enforce these boundaries:

For database access:

• Create a read-only database user for each subagent
• Grant SELECT on specific tables only
• Revoke INSERT, UPDATE, DELETE, DROP
• Use row-level security (RLS) if needed to further limit scope

For API access:

• Issue API keys scoped to read-only endpoints
• Use OAuth scopes to limit what the agent can request
• Implement rate limiting at the API gateway

For external services:

• Use IAM roles or service accounts with minimal permissions
• Apply permissions boundaries if using AWS
• Log all external API calls

Step 3: Build the Orchestrator

Your orchestrator needs:

• Recommendation ingestion: Receive and parse subagent outputs
• Conflict resolution: When agents disagree, apply a tiebreaker
• Business logic enforcement: Apply policies that agents don’t know about
• State validation: Check that the action is still valid
• Write execution: Perform the mutation with full permissions
• Audit logging: Log every decision and outcome
• Error handling: Retry, rollback, or escalate
• Monitoring: Alert on anomalies (e.g., unusually high write volume)

The orchestrator should have write access to your production systems, but that access should be:

• Logged and auditable
• Rate-limited and monitored
• Reversible (with rollback capability)
• Scoped to the specific tables/APIs it needs

Step 4: Add Monitoring and Alerting

Set up alerts for:

• Subagent failures or timeouts
• Recommendation rejection rates (if orchestrator is rejecting > 10% of recommendations, something’s wrong)
• Unusual write patterns (e.g., 10x normal volume)
• Permission boundary violations (attempts to access denied resources)
• Orchestrator latency (if decisions are taking > 5x normal time)

These alerts help you catch bugs and attacks early.

Step 5: Test and Iterate

Before deploying to production:

1. Unit test subagents: Verify each agent’s logic in isolation
2. Integration test: Run subagents + orchestrator against test data
3. Chaos test: Inject failures (agent timeout, bad data, conflicting recommendations) and verify the orchestrator handles them gracefully
4. Load test: Verify the system handles peak load without degradation
5. Security test: Attempt prompt injection, permission escalation, and other attacks

Start with a small cohort of customers or a staging environment. Monitor closely. Gradually roll out to production.

---

Audit Readiness and Compliance Through Permission Design

When you’re pursuing SOC 2 compliance or ISO 27001 certification, auditors will ask:

• How do you prevent unauthorized changes? (Answer: read-only subagents + orchestrator gating)
• Can you prove who made each change? (Answer: audit logs with subagent recommendations and orchestrator decisions)
• What happens if a system is compromised? (Answer: damage is capped by permission boundaries)
• Do you test your access controls? (Answer: yes, chaos tests and security tests)

The read-only subagent pattern is a huge advantage here. It’s not just safer—it’s auditable. You can show auditors:

1. Clear role separation: Subagents read, orchestrator writes
2. Explicit permission boundaries: Each subagent has a declared scope
3. Comprehensive audit trails: Every write is logged with context
4. Tested controls: You have evidence of testing (test reports, security assessments)
5. Incident response: When something goes wrong, you can trace it back to a specific recommendation or orchestrator decision

We’ve helped 20+ clients pass SOC 2 Type II and ISO 27001 audits using this pattern. Auditors appreciate the clarity: there’s a clear chain of custody for every data change.

When implementing via Vanta (a common choice for SOC 2 readiness), you can map:

• Subagent capability declarations → Access Control (AC) evidence
• Audit logs → Logging & Monitoring (LM) evidence
• Permission boundary tests → Testing (TE) evidence
• Incident response playbooks → Incident Response (IR) evidence

This isn’t just compliance theatre. It’s genuine risk reduction that happens to align with what auditors are looking for.

---

Measuring Safety: Metrics That Matter

How do you know your permission boundaries are working? Track these metrics:

1. Permission Boundary Violations

What: Attempts by subagents to access denied resources

Target: Zero in production. Any violation should trigger an alert and investigation.

Why: Violations indicate either a bug in the agent or an attempted attack. Either way, you want to know immediately.

2. Recommendation Rejection Rate

What: Percentage of subagent recommendations rejected by the orchestrator

Target: 1–5% for a healthy system. If it’s 0%, maybe the orchestrator isn’t validating enough. If it’s > 10%, maybe the subagents are broken.

Why: A healthy rejection rate means the orchestrator is catching edge cases and bad recommendations. Too high suggests subagents need retraining.

3. Blast Radius on Failure

What: Maximum number of records affected if a subagent fails or misbehaves

Target: < 1% of your data. Ideally < 0.1%.

Why: Even with read-only access, a misbehaving orchestrator could execute bad recommendations. If subagents are well-scoped, the orchestrator can only affect a small portion of your data before alarms trigger.

4. Audit Log Completeness

What: Percentage of writes that have a corresponding audit log entry

Target: 100%. No exceptions.

Why: If you can’t audit a write, you can’t prove governance. Compliance auditors will flag missing logs.

5. Mean Time to Detect (MTTD) for Anomalies

What: How long after a permission boundary violation or unusual write pattern do you detect it?

Target: < 5 minutes. Ideally < 1 minute.

Why: The faster you detect an issue, the smaller the blast radius. Automated alerting is critical.

6. Rollback Success Rate

What: Percentage of writes that can be successfully rolled back if needed

Target: 100%. Every write should be reversible.

Why: If you can’t undo a bad write, you’re at the mercy of backups and recovery procedures. Reversibility is your safety net.

---

Next Steps: Building Your Safety-First Agent System

If you’re ready to deploy agentic AI with confidence, here’s your roadmap:

Immediate (This Week)

1. Audit your current agent permissions: If you have agents in production, document what each one can access and modify. Look for overly broad permissions.
2. Identify high-risk domains: Which agents could cause the most damage if they misbehave? Prioritise those for tighter boundaries.
3. Define your orchestrator role: Who or what will make write decisions? How will you govern it?

Short-term (This Month)

1. Implement read-only boundaries: Start with your highest-risk agents. Move them to read-only access.
2. Build orchestrator logic: Implement recommendation aggregation, conflict resolution, and write gating.
3. Add audit logging: Log every recommendation and decision. Make sure logs are immutable and tamper-evident.
4. Set up monitoring: Alerts for permission violations, unusual write patterns, and orchestrator latency.

Medium-term (Next Quarter)

1. Test and harden: Run chaos tests, security tests, and load tests. Fix issues that emerge.
2. Document for audit: Write up your access control policy, incident response procedures, and testing evidence.
3. Consider compliance: If you’re pursuing SOC 2 or ISO 27001, map your permission boundaries to audit requirements.
4. Measure safety: Track the metrics above. Establish baselines and targets.

Long-term (Ongoing)

1. Iterate and improve: As you learn what works, refine your orchestrator logic and permission boundaries.
2. Scale safely: As you add more agents, maintain the same safety standards. Don’t let speed compromise governance.
3. Share learnings: If you’re in a portfolio (PE firm) or ecosystem (venture studio), share your safety patterns with other teams.

If You Need a Partner

Building a safety-first agent system is complex. It requires:

• Deep expertise in agentic AI and orchestration
• Cloud infrastructure knowledge (AWS IAM, Kubernetes RBAC, etc.)
• Security and compliance experience
• Operational discipline and testing rigour

If you’re a founder or operator who wants to move fast without taking safety shortcuts, PADISO’s AI & Agents Automation service specialises in exactly this: shipping multi-agent systems with built-in safety, governance, and audit readiness.

We’ve implemented this pattern for customer service automation, financial services fraud detection, healthcare diagnostics, HR recruitment, construction project management, retail inventory, agricultural automation, insurance claims, supply chain optimisation, e-commerce personalisation, education platforms, and government services.

We work as fractional CTO partners for seed-to-Series-B startups and as embedded teams for mid-market and enterprise operators modernising with AI. We also help teams pass SOC 2 and ISO 27001 audits without the usual friction.

---

Summary

Subagent permission boundaries aren’t a nice-to-have. They’re the difference between a controlled AI system and a catastrophic failure.

The pattern is simple: read-only subagents, orchestrator-only writes. Subagents generate insights and recommendations; the orchestrator enforces governance and executes mutations. This creates a clear accountability boundary, caps blast radius, and makes audit readiness straightforward.

We’ve prevented every accidental data deletion, every unauthorised API call, and every compliance violation across 50+ client implementations by enforcing this pattern. It works at every scale—from 5-agent systems to 50+ agent orchestrations.

If you’re shipping agentic AI, start here. Define your subagent capabilities, implement read-only boundaries, build a strong orchestrator, and log everything. The upfront investment in safety pays dividends in speed, confidence, and audit readiness.

Your future self (and your auditors) will thank you.