Tweak: Remove max-runs feature in favour of stop-date

[pelikhan]

the max-runs computation should be implemented as a separate job with the actions: write permission .

The "user job" should have this kind of permission.

githubnext/agentics@b31bd70

[github-actions]

🎯 Agentic Issue Triage

This issue highlights an important security and architectural concern regarding GitHub Actions permission separation in agentic workflows.

Issue Summary

The current implementation requires the main user job to have actions: write permission to compute max-runs, which violates the principle of least privilege. The proposed solution is to separate this computation into a dedicated job with appropriate permissions.

📋 Technical Analysis

Current Problem

• Main workflow jobs require unnecessarily broad actions: write permissions
• This increases the attack surface and potential for privilege escalation
• Users must grant more permissions than actually needed for their workflows

Proposed Solution

• Create separate job specifically for max-runs computation with actions: write
• Keep user jobs with minimal required permissions
• Improves security posture through permission segregation

Architecture Benefits

• Security: Follows principle of least privilege
• Maintainability: Clear separation of concerns
• Compliance: Better aligns with security best practices
• User Trust: Reduces permission requests to users

🛠️ Implementation Strategy

Suggested Approach

1. Create dedicated job for max-runs computation

   • Job with actions: write permission only
   • Outputs results for consumption by user jobs

2. Modify user jobs to consume max-runs data

   • Remove actions: write requirement
   • Use job dependencies and outputs

3. Update workflow templates

   • Ensure generated workflows use new architecture
   • Maintain backward compatibility during transition

Areas to Review

• pkg/workflow/ - Workflow generation logic
• .github/workflows/ - Template workflows
• Permission validation in job compilation

🔍 Security Considerations

Current Security Impact

• Over-privileged workflows increase risk exposure
• Difficult to audit actual permission usage
• Users may be hesitant to grant broad permissions

Post-Implementation Benefits

• Clear audit trail of permission usage
• Reduced blast radius of potential vulnerabilities
• Easier permission review and approval process
• Better alignment with enterprise security policies

✅ Action Items & Checklist

Development Tasks

• Design new job architecture for permission separation
• Update workflow compiler to generate separate max-runs job
• Modify user job templates to consume max-runs outputs
• Update documentation and examples
• Add tests for permission separation
• Validate backward compatibility

Testing Requirements

• Test with various workflow configurations
• Verify permission reduction works correctly
• Ensure max-runs computation remains accurate
• Test job dependencies and output passing

Documentation Updates

• Update workflow authoring guides
• Document new permission model
• Provide migration guidance for existing workflows

Labels Applied

• enhancement: Represents architectural improvement
• security: Addresses permission and privilege concerns
• go: Implementation will likely involve Go workflow compiler code
• ci: Relates to GitHub Actions and CI/CD workflows

This is a well-scoped enhancement that will improve the security posture of agentic workflows while maintaining functionality. The permission separation aligns with security best practices and will likely increase user adoption by reducing permission requirements.

AI-generated content by Agentic Triage may contain mistakes.

[dsyme]

I think we should probably remove the max-runs feature

[dsyme]

Done!